More flexibility in the ECMAScript part?

Tab Atkins Jr. jackalmage at gmail.com
Thu Apr 18 10:08:01 PDT 2013


On Thu, Apr 18, 2013 at 7:42 AM, Mark S. Miller <erights at google.com> wrote:
> You don't need to account for cancellation in terms of event queue
> manipulation. And I agree with (what I believe to be) Jorge's position, that
> it is less clean to do so. Rather, you can just think of the queued event as
> having the behavior "do this if it isn't cancelled" and the cancellation as
> setting a cancellation state to be so tested by that queued event once it
> fires. Of course, if implemented this way, it would fail to reclaim as much
> storage. But that's not an observable difference, so the spec can simply use
> the simpler model.

Further, some event-queue APIs explicitly do auto-cancelling with the
"check just before they would run" semantic.  The name of one I was
discussing with coworkers recently is escaping me, but it's required
to do the just-in-time verifying, because whether or not the event
finally fires is dependent on the state of something else at that
exact moment.

(It could have been written in terms of cancelling, but it would have
been much more complicated, as anything that manipulated the state it
checked would also have to know to clean out the event queue.)

~TJ


More information about the es-discuss mailing list