W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: More flexibility in the ECMAScript part?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 18 Apr 2013 10:08:01 -0700
Message-ID: <CAAWBYDAPyaaPkyijPEf4dM+kiPhXrcz6qWZNGmEsOap1n_nmeg@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: David Bruant <bruant.d@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, EcmaScript <es-discuss@mozilla.org>
On Thu, Apr 18, 2013 at 7:42 AM, Mark S. Miller <erights@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.)

Received on Thursday, 18 April 2013 17:08:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC