> On Jul 7, 2015, at 3:36 AM, Yusuke SUZUKI <utatane....@gmail.com> wrote: > > On Tue, Jul 7, 2015 at 8:54 AM, Geoffrey Garen <gga...@apple.com > <mailto:gga...@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 > > (2) would become the original proposal. > > >> On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak <m...@apple.com >> <mailto:m...@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 <gga...@apple.com >>> <mailto:gga...@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....@gmail.com >>>> <mailto:utatane....@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 >>>> <http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob> >>>> >>>> Best Regards, >>>> Yusuke Suzuki >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
