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

Re: Promise/Future: asynchrony in 'then'

From: Sam L'ecuyer <sam@cateches.is>
Date: Wed, 1 May 2013 12:24:54 -0400 (EDT)
To: "Alex Russell" <slightlyoff@google.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "es-discuss" <es-discuss@mozilla.org>
Message-ID: <1367425494.953112768@apps.rackspace.com>
>> Juan already pointed out the "queue a task" language, so this is answered.


> This is far too glib. The spec may very well be wrong on this point. The
> design goal isn't to require a full yeild of the event loop, but instead to
> force async code flow -- that means that resolving and calling back should
> be able to happen at "end of microtask"; the same timing as
> Object.observe() callbacks.

Promises/A says has an open issue on whether callback handlers should be put on the event queue or executed immediately.

Promises/A+ & Promises/B both specify that callbacks may not be invoked in the same turn of the event loop. 
 
According to the harmony:observe doc, it was suggested that "Schedule change events to be delivered asynchronously “at the end of the turn”".

These may all be wrong, but all seem to be hitting at the fact that "in a new turn" is the *easiest* way to force asynchronicity.  Maybe we need to specify that all callbacks must be invoked asynchronously, regardless of which turn in the event loop they occur.

-s
Received on Wednesday, 1 May 2013 16:25:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC