Bringing setTimeout to ECMAScript
wes at page.ca
Fri Mar 18 21:43:27 PDT 2011
On Fri, Mar 18, 2011 at 7:26 PM, Brendan Eich <brendan at mozilla.com> wrote:
> > If we can define a concurrency model, then we can build setTimeout.
> See my previous reply. JS with setTimeout has only pseudo-concurrency via
> time-deferred script executions or function calls. There's nothing
> concurrent in a racy sense there.
pseudo-concurrency is a type of concurrency. I expect that any concurrency
model standardized into ES will be event-loop concurrency, as implemented
today in every browser and most server-side platforms that have any kind of
concurrency at all.
Various implementors have found that setTimeout(f, 0) that calls f
> immediately "breaks the web" (or at least the New York Times site).
> Similarly, waiting an event loop turn seems to break the web. By testing,
> 4ms has been arrived at. I welcome fresher data.
I don't have "breaks the web" data, but executing f before setTimeout()
returns (rather than wait for us to get back in the event loop) changes the
semantics of the program. This might seem obvious, but I have seen the
analogue in suggestions in under the CommonJS umbrella for both module
loaders and promises, where the authors were trying to unify the "async"
(wince) and "sync" (more wincing) environments of systems with and without
event loops. I have pointed out in those contexts that to insure
deterministic program results that some kind of event loop needs to be used
even platforms like the one Kyle was describing.
You introduced the term isosynchronous in this thread. Could you define it
in this context? I am frustrated by the vocabulary I normally see used when
considering systems with and without event loops. "async" and "sync" hurt
me. For the time being, I'm assuming by isosynchronous you mean the same
concurrency model as a C program on UNIX with neither threads nor fork.
> > - forbidding eval-like syntax
> What problem are you solving?
I suggested that for consideration, and after considering it, withdraw that
suggestion, substituting instead the suggestion that setTimeout() forms
which accept string arguments should behave as though they were lazily
evaluated with indirect-eval.
My off-the-cuff suggestion attempted to solve the programmer-confusion
problem I see surrounding setTimeout. The main problem with my suggestion,
of course, is that you can't put the cat back in the bag.
What do you mean by conditionals? If you mean condition variables, JS will
> never grow to include shared-mutable-state threads. That would happen not
> only over my dead body, but the rest of TC39's. We'd fight back, so watch
Good Lord, no. I was actually thinking of gdb watchpoint conditions when I
wrote that. SetTimeout is, after all, just a way to place a hunk of code
on the event loop that conditionally runs based on the clock.
Wesley W. Garland
Director, Product Development
+1 613 542 2787 x 102
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss