Re: Sync API for workers

On Sun, Oct 13, 2013 at 1:36 PM, David Bruant <bruant.d@gmail.com> wrote:
> Le 13/10/2013 21:39, Jonas Sicking a écrit :
>
>> Ok, this thread is clearly heading off the deep end. Let me clear up a
>> few points of confusion:
>>
>> * You can not wrap a truly synchronous library around an asynchronous
>> API. Spinning the event loop gets you close, but breaks
>> run-to-completion. Furthermore, spinning the event loop is irrelevant
>> as we don't have an API to do that, nor are we planning to introduce
>> one.
>> * yield only works within generators in JS.
>
> To be honest, I feel generators will be interoperably deployed cross-browser
> long before sync APIs in workers. V8 and SpiderMonkey already have
> generators. I'm not entirely sure it's 100% compliant in SpiderMonkey yet,
> but for sure it's being actively worked on and should be soon if not yet.

I would expect that too, but that's beside the point given that yield
doesn't actually solve the problem. See below.

>> * You could solve the use case of compile-to-JS for code that uses
>> sync APIs using yield. However it requires changing all functions into
>> generators, and all function calls into yield* statements.
>
> all? as is "all function in the application"? that sounds like a too violent
> constraint, especially if a small proportion of the code uses sync
> functions. Maybe only the functions that may call a sync function need to be
> changed to generators... oh... hmm... I don't know.

"All" as in "all that directly *or indirectly* call the sync API".

>> That comes
>> at a performance overhead that is significant enough as to make it an
>> unacceptable solution (several times slower in current
>> implementations).
>
> I guess this point depends on the previous one. Given that compile-to-JS has
> wind behind these days, generators may benefits from optimizations.

Generators certainly can be made faster. But given that they always
result in stopping to use the CPU mechanisms for function calls I'd be
very surprised if the performance can be made good enough.

>> * yield would not solve the use-case of allowing libraries that use
>> features from the main thread as it, again, would require a rewrite of
>> all code that directly or indirectly uses that library to change all
>> functions into generators and all function calls into yield*.
>
> I think this point is about interoperability between main thread and worker.
> I don't remember this point being discussed too much yet.

See my original email. Workers are likely to always lag behind main
thread. And some APIs aren't currently slated for workers at all. In
particular ones that involve UI or the DOM.

> What about exposing both async and sync APIs to workers?

What about it? We could certainly add lots of sync APIs to workers.
But if one of the main use cases is compile-to-JS of existing pre-web
codebases, which presumably over the years will become less of an
issue as people target the web directly, then finding a smaller
surface like my proposed API seems beneficial to lots of specialized
sync APIs.

/ Jonas

Received on Sunday, 13 October 2013 21:21:41 UTC