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

On Wed, Mar 9, 2011 at 6:58 AM, Adrian Bateman <adrianba@microsoft.com>wrote:

> 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.
>

I think this alternate lifetime model is practically unimplementable in a
world where workers and pages live in multiple processes. The reason is that
the linkage between nodes in your graph depends on reachability of ports
which can't really be established simultaneously across processes - I think
you end up with cycles in the graph that can't easily be resolved.


>
> 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.
>

I guess I don't understand the implementability concerns that would lead to
adopting #2. Your example below seems largely identical to:

Document creates two workers, W1 and W2
Document creates a MessageChannel and gives one port to each worker
Document removes all references to the worker objects, so those two ports
are the only thing keeping W1 and W2 alive.

I don't understand why we would treat this case differently than your case
(where a third worker actually performs the creation).

Let me provide a useful real-life example:

1) Document creates worker W1 and immediately drops its reference to it so
it is no longer reachable. W1 is still protected because it has not run its
initial script yet.
2) In its startup script, W1 creates two workers, W2 and W3, and immediately
drops references to them. W1 is permissible, but no longer protected, and
could be closed at any time.
3) W2 and W3 run their startup script to do some quick processing, and when
complete they will upload the results to the server.
4) Since W1 is no longer protected, the system could close it, so let's say
W1 gets closed now.

With the spec as it currently stands, W2 and W3 would continue to run as
long as the parent document stays alive, and they would complete their
processing and submit the results to the server.
With your suggested change, W1 would close, and that would cascade to W2 and
W3, cancelling their operation. So developers would be forced to find a way
to keep W1 alive for the duration of the execution of W2 and W3 to prevent
them from being prematurely closed, either by timers, or by holding
references to resources (like protected workers W2 and W3) that they don't
need.

So I'm not certain that the lifetime specification you describe has the
desired behavior in the case of fire-and-forget workers (workers that don't
need to interact with their parents).


> 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
>
>