On Sat, Mar 19, 2011 at 5:59 AM, David Bruant <david.bru...@labri.fr> wrote:
> Le 19/03/2011 07:02, David Herman a écrit : > > It seems to me there are a couple pieces to Mark's concurrency proposal. > One part is formalizing the event queue that already exists. > > Is this already done in the current proposal? Because I haven't found it. > Regardless, this work of formalizing the already existing event queue has > already been done by the WHATWG: > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops > I think it would be a mistake to start the formalization work from scratch > since a decent part of the work has already been done. > > > > Another part is introducing new concepts and features to the language (like > promises and vats). > > I want to hear what Mark has to say at the TC39 meeting, but my gut tells > me it's too early to introduce new concurrency constructs for ES.next. > There's actually a lot you can do with closures and objects (such as the > promises libraries people have been experimenting with lately). And with > generators, you can implement some really convenient constructs. I've > recently been building a concurrency library called jsTask, that makes it > possible to write blocking computations in a really natural style: > > > http://blog.mozilla.com/dherman/2011/03/11/who-says-javascript-io-has-to-be-ugly/ > http://dherman.github.com/jstask/ > > Once, I read the concurrency proposal with in mind "can setTimeout be > implemented with what is in this proposal?". I have found the timeout > section ( > http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts) and > I thought "awesome!"... until I realized that this example is itself using > setTimeout (which is consistently implemented in most ECMAScript-based > environments but isn't itself part of any ECMAScript version). > ( By the way, there is a typo in this example. I think that > "setTimeout(const(){...}, 0)" should be "setTimeout(const(){...}, millis)", > where "millis" is the second argument. ) > Good catch. Fixed. Thanks. > > I fully agree that the current proposal and all related work (yours > included) offer very powerful mecanisms and solutions to common problems (I > had already read your article on "Who says JavaScript I/O has to be ugly?" > and really enjoyed what I saw). However, the tiny > brick/element/component/part that is missing to implement "time event" > ("clock event"?) is to take time into account in the proposal. No matter how > powerful the current proposal is, it is lacking this elementary piece in > order to implement/standardize setTimeout. > And I intuit it wouldn't be that hard to add it. I am not very familiar > with promises but from what I understand, having the ability to create a > "timed promise" which resolution would be handled by the engine could be a > solution. Once again, I'm not familiar with promises, so this idea may sound > stupid, but people who are familiar with promises and the Q API will > certainly have better ideas on integrating the notion of time to the concept > in a way that could make setTimeout and friends implementable on top of this > integration. > The idea is not stupid at all. It's perfectly sound. For example, the delay example you noticed could be made primitive and setTimeout built out of that. Either can be built from the other. The advantage of layering setTimeout on a new primitive, whether delay or < http://nodejs.org/docs/v0.4.3/api/all.html#process.nextTick> or something else, is that the new primitive can avoid spec weirdnesses already entrenched for setTimeout, like this 4ms clamping. Instead, this 4ms weirdness could just be specifically part of setTimeout's behavior. Layering the other way, with setTimeout at the bottom, would mean the event loop could never run faster than 4ms per turn. This is unacceptable, and probably has been since the mid '70s. Should we clamp our fast our CPUs can execute instructions as well? That said, I think something like setTimeout with better semantics is the right lower layer abstraction. The two things I'd fix in this lower layer abstraction: * No clamping. Time runs as fast as the platform lets it run. * The return value is not an integer but a unique unforgeable object for canceling the event. No one without that object can cancel that event. Then I'd layer promise-based conveniences, like delay, on that. > > As for event queue semantics, I think in principle that Ecma-262 is a > reasonable place to specify it. It doesn't rely on specifics of the browser, > and Node.js is a testament to that. (Besides, a non-interactive setting > could probably be modeled as a trivial event queue, i.e. one with just a > single "run the program" event.) I'm not sure whether this is worth trying > to accomplish in time for ES.next, though. > > Does the fact that some event loop formalization work has already been done > by the WHATWG within Standard HTML change your opinion on the matter? > > David > > > > Dave > > On Mar 18, 2011, at 5:51 AM, David Bruant wrote: > > Hi, > > _Foreword_ > Each time I write "setTimeout", I mean "setTimeout and setInterval (and > there clear functions)" (please forgive the recursive flaw) > > _Introduction_ > Before the concurrency proposal ( > http://wiki.ecmascript.org/doku.php?id=strawman:concurrency), a pure > ECMAScript program had a start and an end, that was it. No event loop, no > asynchronous callback, etc. > If ECMAScript standardizes this proposal or another, there will be a need > to standardize an event loop in a way or another. Adding a timing aspect to > this event loop and setTimeout can be standardized in ECMAScript. > > _Current_standardization_state_ > setTimeout isn't part of ECMAScript. setTimeout is nonetheless standardized > as part of "HTML Standard" ( > http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers). > Besides the "task" dependency (which is part of the standardized event-loop > in the same document: > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task), > this is more or less ECMAScript. > > _Current_use_ > As anyone will have certainly noticed, setTimeout has no reason to be > considered as client-side web specific. And, as a matter of fact, there is a > setTimeout in node.js and in ActionScript apparently. I wouldn't be > surprised if most (if not all) ECMAScript-based languages had a setTimeout > function consistently. > > For all these reasons, I am wondering if setTimeout wouldn't be had being > standardized in ECMAScript itself. > > _How?_ > I currently see two main tracks: > * Standardize it as it is. > * Standardize a more powerful mecanism and standardize setTimeout as an > implementation based on this mecanism. If setTimeout had been considered as > not flexible enough by some people, this could be an occasion to fit their > use case (I personnally have no suggestion on the matter) > I am not familiar with promises, but after reading a bit about it and > seeing a presentation on the topic, I intuit that it may not be very > difficult to add a timing aspect to it based on which setTimeout could be > implemented. > > _Advantages_ > * As said, it could be an occasion to fix flexibility issues that people > would find to setTimeout > * Define a strict mode behavior to it. Currently, people can pass strings > as first argument to setTimeout. There is currently a spec hole in what > happens in strict mode for setTimeout. > I would be in favor to throw an exception if people use strings in > setTimeout in strict mode (maybe it's too late to suggest that since FF4 > ships in less than a week?). Anyway, there is room for other ideas like > standardizing strict eval for strings as first argument in strict mode. My > main goal is to discuss the issue. > > > I haven't found any trace of previous discussion of this topic. Has there > been any? > > David > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing > listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
