Bringing setTimeout to ECMAScript
jorge at jorgechamorro.com
Mon Mar 21 03:47:48 PDT 2011
On 21/03/2011, at 00:21, Bradley Meck wrote:
> It isn't in the past though, it is scheduled to be run as soon as
> possible past a certain point. That being said `as soon as possible`
> may not be in a particular order (os schedulers / threads / event
> listeners in js for example). I view this close to even listeners in
> the respect that schedule of events cannot be determined. While it may
> appear to be logical to have events FIFO based upon maxage, most other
> systems besides a simple manual iteration of a set do not follow this.
> I don't schedule events in a particular order because I have never
> encountered a situation where I would want 2 timers where I couldn't
> schedule the 2nd one that depends upon the first, after the first. Is
> there a situation where it makes sense to have
> where g depends f instead of:
> Which is more verbose, but far clearer on intention.
> 1. This allows for the linear fashion that people may desire, without
> causing limiting behavior on the scheduler.
> 2. This is much more clear that g should fire 10milliseconds after f
> rather than possibly immediately after f (which presumably is what the
> example wants).
> 3. It encourages less `magic` in how things are scheduled.
> Expectations of manipulation are lowered and code design is encouraged
> over engine implementation.
> The fact that you say an order should be honored is a bit misleading
> for 2 facts.
> 1. I would expect g to fire 10ms after f, but it may fire immediately.
> 2. By design it separates the dependent functions f and g so I have no
> reason seeing that code to expect g to rely on f.
> So while you may see this as being an expectation of FIFO based upon
> max age, I merely see it as after x milliseconds something should be
> fired, nothing more, no magic.
I don't think there's any magic in this:
1.- If you could service every timer at exactly its target time, that would be the expected order.
2.- If you can't, because Date.now() is already > their target times, well, just service them in the expected order, as in (1).
More information about the es-discuss