On Fri, Mar 18, 2011 at 7:26 PM, Brendan Eich <[email protected]> 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 > out. > 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. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
