RE: publish Last Call Working Draft of Web Workers; deadline March 7

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-request@w3.org [mailto:public-webapps-request@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

Received on Wednesday, 9 March 2011 14:59:01 UTC