On Mar 18, 2011, at 9:43 PM, Wes Garland wrote: > 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.
Good point. > You introduced the term isosynchronous in this thread. Could you define it > in this context? Something occurring at a regular interval. Obvious setInterval is more precisely isochronous but my point was that, ignoring clamping and latency in the scheduler and due to (virtualized-by-JS and virtualized-by-the-OS) CPU hogging, timeouts run at some number of msec in the future. Not like i/o which may happen indefinitely later (but within the TCP connection timer ;-). Read more: http://www.answers.com/topic/isochronous#ixzz1H1O5GiCJ > 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. Not what I meant, although you could imagine pause between script, event handler, and timeout runs (event loop turns), and whatever signal has good enough resolution for alarming the pausing process. You're right that "async" is abused and confusing enough that we wince. "Event loop concurrency" is a mouthful but hits the general execution model target. "No preemption" is important. And for setTimeout and setInterval, talking about time-based turns, reliable within some constraints modulo quality of implementation and availability denial issues, must matter. /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
