Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define tasks for state changes #218

Closed
alexshalamov opened this issue May 27, 2017 · 5 comments · Fixed by #197

Comments

@alexshalamov
Copy link

commented May 27, 2017

At the moment, spec has few places where state is updated without task or (state change + simple event) is fired outside of task execution scope.

According to recommendations from Anne state changes should be performed from task.

Also, spec must define what happens to tasks that are in the queue, e.g., whether those can be cancelled (removed from queue).

Example 1:

Sensor is active and update reading is queued, then error occurs and page loses visibility.
Now we have 3 tasks in queue [update sensor reading, onerror, state change to idle].

Should we process queue and don’t allow new tasks to be added from sensor? Should we 'suspend' tasks and wait when page gains visibility and then process tasks?

Example 2:

Sensor is is active, update sensor reading scheduled, then stop is called.

Two tasks in queue [update sensor reading, change state to idle]
Should we cancel queued update?

@tobie

This comment has been minimized.

Copy link
Member

commented May 27, 2017

We'll see what the simplest solution to this is.

Given the reason of suspension (mitigate skimming) eventually allowing one reading to get through isn't an issue.

@tobie tobie modified the milestone: Level 1 May 30, 2017
@tobie

This comment has been minimized.

Copy link
Member

commented May 30, 2017

Example 1:
Sensor is active and update reading is queued, then error occurs and page loses visibility.
Now we have 3 tasks in queue [update sensor reading, onerror, state change to idle].

Page looses visibility is not going to queue anything afaik.

Should we process queue

Yes.

and don’t allow new tasks to be added from sensor?

Not sure what you mean by that, but the sensor can continue adding new tasks (for example if it's re-started).

Should we 'suspend' tasks and wait when page gains visibility and then process tasks?

No, they're queued and can be processed right away.

Example 2:
Sensor is is active, update sensor reading scheduled, then stop is called.
Two tasks in queue [update sensor reading, change state to idle]
Should we cancel queued update?

No.

tobie added a commit to tobie/sensors that referenced this issue May 30, 2017
@tobie

This comment has been minimized.

Copy link
Member

commented May 31, 2017

Alright, so I checked with Anne and that was an excessive interpretation of his words.

Queuing tasks are really meant to handle boundary conditions with async events to maintain JavaScript's single-threaded nature. So it's essentially useful for us when passing new readings to JS.

Still checking to see if/when to apply it to events, as that part is still unclear to me.

@alexshalamov

This comment has been minimized.

Copy link
Author

commented May 31, 2017

Anne was right, we should update states + fire event from tasks when we get some async events, e.g., from platform.

Due to single threaded nature of JS for things like start / stop, we are executing code in same call-chain, so, this issue might not be applicable.

For things that run 'in parallel', we need to queue new tasks.

@tobie

This comment has been minimized.

Copy link
Member

commented May 31, 2017

Yeah. That's pretty much what I said. ;)

@alexshalamov alexshalamov added this to In Progress in Level 1 Jun 29, 2017
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Jun 30, 2017
…d internal slots used in the Sensor interface specification.

The refactoring goals are:

1) Stop firing events synchronously.
2) Clean up the internal slots after stop or error.
3) Fix logical errors in the abstract operations.
3) Recompose abstract operations so that duplication of the algorithms steps is removed.
4) Drop the unused abstract operations and internal slots.

Fixes w3c#199
Fixes w3c#200
Fixes w3c#201
Fixes w3c#203
Fixes w3c#218
Fixes w3c#215
Fixes w3c#204
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Jun 30, 2017
…d internal slots used in the Sensor interface specification.

The refactoring goals are:

- Stop firing events synchronously.
- Reset internal slots values after stop.
- Fix logical errors in the abstract operations.
- Recompose abstract operations so that duplication of the algorithms steps is removed.
- Drop the unused abstract operations and internal slots.

Fixes w3c#203
Fixes w3c#218
Fixes w3c#215
Fixes w3c#204
Fixes w3c#126
Fixes w3c#243
@alexshalamov alexshalamov removed this from In Progress tasks in Level 1 Jul 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.