W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] navigator.yield()? (Was: localStorage + worker processes)

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 24 Mar 2009 20:58:32 +1300
Message-ID: <11e306600903240058w7e5e8350n3f40e80289f3dcae@mail.gmail.com>
On Tue, Mar 24, 2009 at 1:17 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 23 Mar 2009, Jonas Sicking wrote:
> >>
> >> And that's not even touching on the stack space limitations that you're
> >> quite likely to run in to when you have an API specifically for nesting.
> >
> > I think any sane implementation of this would have to be non-recursive.
> > That's part of why I think it'd be so hard to implement.
>
> Indeed, that'd be really hard to implement in the generic case. For
> example a navigator.yield() inside an event handler, or inside a
> callback.
>
> We'd basically have to redesign all the code that implements the DOM
> and all other APIs that are exposed to javascript.
>
> Or rewrite our code in a language that supports continuations, which
> C/C++ doesn't do. (no, setjmp and longjmp doesn't count :) ).
>

Not necessarily, it depends on the semantics. For example, you might retain
the option for "yield" to do nothing (i.e. it offers no liveness
guarantees). In that case you would have the option of not yielding in
difficult situations like event handlers or callbacks, or if recursion gets
too deep. Or a spec could say which script executions allow yielding and
which don't.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090324/91f10693/attachment.htm>
Received on Tuesday, 24 March 2009 00:58:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT