[webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

[Yusuke SUZUKI]

On Wed, Jul 8, 2015 at 4:07 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 7, 2015, at 3:36 AM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
>
> On Tue, Jul 7, 2015 at 8:54 AM, Geoffrey Garen <ggaren at apple.com> wrote:
>
>> I’m suggesting a default runloop for non-web content.
>>
>> I haven’t read through the details of integrating with the web content
>> definition of micro task.
>>
>> Geoff
>>
>
> OK. Reinventing runloop each time is costly.
> On the other hand, sometimes, users would like to use the other runloop
> such as libuv.
> So what do you think about providing the both.
>
> 1. Provide default runloop in JSC
> 2. Provide the way to register callback for enqueueJob. If it's provided,
> (1) is disabled for this VM.
>
> (1) would become the following (quick proposal)
>
> void JSContextRunMicrotasks(JSContextRef, unsigned someFlags);
> bool JSContextIsMicrotasksEmpty(JSContextRef);
>
> In this case, if we would like to close the VM,
>
> bool executed = false;
> do {
>     executed = false;
>     for each context belongging to the given VM {
>         if (JSContxtIsMicrotasksEmpty(context)) {
>             executed = true;
>             JSContextRunMicrotasks(context, ...);
>         }
>     }
> } while (executed);
> Close(VM);
>
>
> I think that Goeff's suggest would be that microtasks would normally run
> without the client having to make any special calls at all to account for
> them. Possibly this may imply a requirement of running a CFRunLoop on the
> relevant thread.
>
> I also think your API doesn't account for nesting very well - it requires
> the client app to know the VM nesting level. It would be better if that was
> tracked and micro tasks could run on exiting the outermost VM and/or
>
>
I see, thanks :D

Counting the nesting level and when the nesting level becomes 0 and at the
epilogue of the JSC APIs, draining queued microtasks.

I guess VM's apiLock (locked by JSLockHolder) already counts the VM depth
and manages API's scope. Leveraging this could solve the requirements I
think. (Of coursing, kicking some processing in the C++ destructor is not
good. When leveraging this mechanizm, we need to consider the way anyway.)


>
> (2) would become the original proposal.
>
>
>>
>> On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>
>> Should JS be defining an event loop abstraction that WebCore then uses?
>> That would be weird, because the required behavior of the even loop in web
>> content is chock full of issues that are not at all related to JavaScript.
>> JSC doesn't even know enough to run microtasks at all the right times (from
>> reading the spec it seems that way, at least) for the Web case. Or are you
>> saying it would have a fallback runloop for non-Web contents?
>>
>> Regards,
>> Maciej
>>
>> On Jul 6, 2015, at 3:24 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>>
>> I think it would be better for JavaScriptCore to handle micro tasks
>> natively.
>>
>> It’s not so great for each client to need to reinvent the microtask
>> runloop abstraction.
>>
>> Geoff
>>
>> On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
>>
>> Hi WebKittens,
>>
>> I've landed the update of the ES6 Promise implementation.
>> Through this work, I've experimentally added the internal private
>> function, @enqueueJob(JS function, JS array for arguments).
>> This is corresponding to the ES6 spec EnqueueJob[1].
>>
>> This EnqueueJob handler is now tightly integrated with WebCore's
>> microtask infrastructure. So in JSC framework side, we cannot use this
>> function.
>> As a result, current JSC framework disables Promise because there's no
>> event loop abstraction.
>>
>> So I propose the API configuring euqueueJob handler into JSC VM (That
>> corresponds to the Realm in ECMA spec).
>>
>> Like,
>>
>> void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef,
>> JSEnqueueJobCallback, void* callbackData);
>>
>> What do you think about this?
>>
>> [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
>>
>> Best Regards,
>> Yusuke Suzuki
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150708/d8b6c801/attachment.html>