On Wed, Jul 8, 2015 at 4:07 AM, Maciej Stachowiak <[email protected]> wrote:
> > On Jul 7, 2015, at 3:36 AM, Yusuke SUZUKI <[email protected]> wrote: > > On Tue, Jul 7, 2015 at 8:54 AM, Geoffrey Garen <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >> >> > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
