Re: Future feedback

On 14/05/13 11:04 PM, David Bruant wrote:
> Le 14/05/2013 04:40, Sean Hogan a écrit :
>> On 13/05/13 1:37 PM, Jonas Sicking wrote:
>>> On Sun, May 12, 2013 at 7:31 PM, Boris Zbarsky <bzbarsky@mit.edu> 
>>> wrote:
>>>>> Moreover the page can be reflowed between tasks.
>>>> _ANY_ async solution will have this property.  What does it even 
>>>> mean to be
>>>> async if you don't allow reflows in the meantime?
>>> Work that is performed at end-of-microtask is sort of between fully
>>> asynchronous and normal synchronous. Since it runs as part of the same
>>> task it means that reflows can't happen before the end-of-microtask
>>> work happens.
>>>
>>> This means that you get some advantages of asynchronous code, such as
>>> not having to worry about being in an inconsistent state due to code
>>> higher up on the call stack being half-run. And likewise you don't
>>> have to worry about not messing up code higher up on the callstack
>>> which didn't expect to have things change under it.
>>>
>>> But it also means that you are missing out of some of the advantages
>>> of asynchronous code, such as you still have to worry about hogging
>>> the event loop for too long and thus not processing pending UI events
>>> from the user.
>>>
>>
>>
>> Thanks for interpreting my comment.
>>
>> As I asked Boris, how could "queuing a task" be abused more than DOM 
>> Future could be?
> I'm a bit confused by terminology and don't know where to jump in in 
> this thread, but I believe this message [1] is relevant. It suggests 
> that the inner&outer event loop (or task/microtask) model is being 
> considered for ES7 standardization.
>


Yes, the terms have context specific meanings beyond their face value.
I'm happy to say "I wish scripts could queue a *micro-task*".
But as a front-end dev I don't feel the terminology matters that much:

a. If the browser can schedule my tasks (micro-tasks, whatever) in a 
timely manner - and without unnecessary page reflows - then I don't care 
how.
b. Since the browser can't (e.g. "just use setTimeout") then I can roll 
my own - emulating the micro-task queue - resulting in longer execution 
blocks.


Perhaps some demo code for (b) is a better explanation.
Assume that the browser provides a `queueTask` function (in current 
browsers this could be satisfied by a setImmediate polyfill, e.g. 
https://github.com/NobleJS/setImmediate)
I use that to create my own `queueMicroTask` function.
If a micro-task queues another micro-task, the second micro-task is 
still executed within the same task. The only time that `queueTask` 
needs to be called is in event handlers, setTimeouts, and <script> 
execution.

var queueMicroTask = (function() {

var queue = [];
var scheduled = false;

function queueMicroTask(fn) {
     queue.push(fn);
     if (scheduled) return;
     queueTask(process);
     scheduled = true;
}

function process() {
     while (queue.length) {
         var fn = queue.shift();
         isolate(fn);
     }
     scheduled = false;
}

return queueMicroTask;

})();


This is quite straight-forward and I'm not sure why I don't see it 
everywhere. The only complexity (currently) is in emulating `isolate` 
and a performant `queueTask`.

I think Jorge covered some of the same ground in his post.

Received on Thursday, 16 May 2013 01:09:09 UTC