Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
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
Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
On Wed, Jul 8, 2015 at 4:07 AM, Maciej Stachowiak m...@apple.com wrote:
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 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 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 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 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@lists.webkit.org
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
On Tue, Jul 7, 2015 at 8:54 AM, Geoffrey Garen 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);
(2) would become the original proposal.
On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak 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 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 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@lists.webkit.org
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
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 On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
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 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org 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
Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks
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 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 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
