Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of the web worker lifetime model (Section 4.4),
dedicated
workers are allowed to enter into an "orphaned" state where they have a message
port
that is keeping them alive (see example at the end of this feedback). We can
imagine
scenarios where the orphaned workers are still able to provide "results" to a
document
(e.g., via connecting to a shared worker), however these use cases 1) seem
largely
irrelevant, 2) can be handled by shared workers if needed and 3) overly
complicate the
implementation (in our analysis) of dedicated workers.
We note that no browser appears to implement the lifetime model as specified in the
latest editor's draft (that we can test).
As we've investigated potential alternate lifetime models (for dedicated workers only),
we came up with two additional potential models:
1 - Lifetime based on a dedicated worker's document "reachability"
This alternate lifetime model keeps a dedicated worker alive until it can no
longer
communicate with the document(s) to which it is associated (through its
implicit port
or any other port). This proposed lifetime model is based on graph
reachability, where
the nodes in the graph are web workers and the arcs in the graph are implicit
and
explicit message ports owned by a worker (i.e., "the worker's ports"). A
dedicated
worker's lifetime is managed by whether the dedicated worker can "reach" the
document(s) in its list of "the worker's documents". See the example at the end
for
how the currently speced lifetime model changes with this approach.
2 - Lifetime that prevents orphaning dedicated workers
In this alternate lifetime model, orphaned dedicated workers are never allowed,
and
the lifetime of the worker is strictly controlled by its implicit port.
Therefore,
whenever a worker creates another worker, if the "parent" worker is terminated
or
closed, then the "child" worker will be terminated or closed as well
(preventing the
child from becoming an orphan). This model is enforced regardless of other
message
ports that the child may have.
It is our opinion that the lifetime model for dedicated workers as currently speced:
1. Overly complicates the implementation
2. Supports corner-case scenarios that have questionable mainstream benefit,
compared to the perception of the currently specified design being
considered a
bug (e.g., the web developer creates a scenario where the orphaned worker
remains
alive, but did not actually intend for this to happen)
3. Provides overlapping scenarios with shared workers (e.g., if the web
developer
really intended the dedicated workers to remain alive as orphans, then
they could
use a shared worker to accomplish the same task instead)
We ask that this feedback be considered and are specifically looking for
1) a justification of the scenarios enabled by supporting dedicated workers in
an
orphaned state and 2) scenarios we may not have considered where an orphaned
dedicated
worker could not be substituted for a shared worker to accomplish the same task.
Should a change to the spec be made as a result of this feedback, we would propose
that alternate lifetime model #2 above be considered instead (not allowing
orphaned
dedicated workers). Alternate approach #1, while less of a change, is
considerably
harder to implement than #2 given the graph reachability problem involved.
It is also worth noting that current versions of Opera appear to implement the
dedicated worker alternate lifetime model #2 above, though we don't know what
decisions led to that conclusion from their point of view.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are "parent" workers and W2 and W4 are "child"
workers.)
5. W1 creates a message channel and passes the channel's ports to document
'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to document
'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's ports to
'W2' and 'W4'
(W2 and W4 now have a direct communication channel between themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be disentangled [step 15 of
section 4.5
processing model] which effects W2's implicit port; however, W2 is not
terminated
because it is still considered a "protected" worker, since its list of
the worker's
ports is not empty.)
9. Document 'D' terminates worker 'W3'
('D' still has communication ports with W2 and W4 and can test that they
are still
alive. W2 and W4 are now "orphaned" from their original creator, but
still have a
connection to the document 'D'.)
10. Document 'D' closes the port connected to 'W2'
(W2 is now only connected via a message port to W4, and can send
information to
'D' via W4.)
11. Document 'D' closes the port connected to 'W4'
(Document 'D' now has *no* connections to W2 or W4-those workers are
completely
orphaned from it. However, W2 and W4 are still alive because they are
"protected"
since they have a message port connection to each other.)
At this point, the only way (that we can think of) for W2 and W4 to "report back" to
document 'D' is by connecting to a shared worker that can broker communications
between
these workers and document 'D' (if document 'D' connects to this same shared
worker).
The moment that W2 and W4 close the ports between them, they are no longer "protected"
and can be closed per step 5 of section 4.5 processing model.
Adjustments to the lifetime based on alternate lifetime proposal #1:
* At step 10 above, W2 remains alive because it can still communicate with
'D' via
it's connection through W4. Therefore it's document 'D' is still
"reachable".
* At step 11 above, both W2 and W4 are no longer 'reachable' from 'D'. At
this point,
this alternate lifetime model would propose that W2 and W4 may be closed.
Adjustments to the lifetime based on alternate lifetime proposal #2:
* At step 8 above, the termination of W1 would cause a "cascade termination"
of W1's
list of "the worker's workers" which would immediately cause W2 to be
terminated
also. Document 'D' could know that this happened because 'D's port to W2
would no
longer respond to messages.
* At step 9 above, the termination of W3 would terminate W4 as previously
outlined.
At this point, all dedicated workers owned by 'D' would be terminated
leaving no orphans.
_______________________
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Monday, February 28, 2011 7:31 AM
To: public-webapps
Subject: CfC: publish Last Call Working Draft of Web Workers; deadline March 7
This is a Call for Consensus (CfC) to publish a new Last Call Working Draft of
the Web Workers spec based on the following version of the spec (copied from ED
version 1.276):
http://dev.w3.org/html5/workers/publish/LCWD-workers-201103TBD.html
This CfC satisfies the group's requirement to "record the group's decision to
request advancement" for this LCWD.
Note the Process Document states the following regarding the
significance/meaning of a LCWD:
[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Purpose: A Working Group's Last Call announcement is a signal that:
* the Working Group believes that it has satisfied its relevant technical
requirements (e.g., of the charter or requirements document) in the Working
Draft;
* the Working Group believes that it has satisfied significant dependencies
with other groups;
* other groups SHOULD review the document to confirm that these dependencies
have been satisfied. In general, a Last Call announcement is also a signal that
the Working Group is planning to advance the technical report to later maturity
levels.
]]
Positive response to this CfC is preferred and encouraged and silence will be
assumed to mean agreement with the proposal. The deadline for comments is March
7. Please send all comments to:
public-webapps@w3.org
Assuming there is consensus to publish this LCWD, the tentative publication
plan is to publish it on or around March 10 with a 6-week comment period ending
approximately April 14.
-Art Barstow
