Re: Sync IO APIs in Shared Workers

On Fri, Nov 22, 2013 at 7:54 AM, Glenn Maynard <glenn@zewt.org> wrote:
> But, we should explore the use cases more thoroughly first, to see if this
> is really needed.  An alternative is to just terminate() the whole worker
> and start a new one.  That's not very elegant, but it's very simple and
> robust: you don't end up with synchronous APIs throwing exceptions
> unexpectedly and worker code having to clean up after it.  If the work is
> expensive enough that you need to cancel it, the cost of spinning up a new
> worker is negligible.

What data are you basing this statement on?

>> Something else that could improve responsiveness while still allowing
>> people to write synchronous code is the ability to check if there are
>> pending messages on a channel without having to return to the event
>> loop. That way the code can keep running until there's a message to
>> process, and only return to the event loop when there is.
>
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html
>
> The proposal is to allow polling a MessagePort, retrieving the next message
> without having to return to the event loop.

I don't like that solution since it's very similar to spinning event
loops in deep call stacks. Having worked on code bases which does
event loop spinning on deep call stacks it's a horror I wouldn't want
to impose on anyone.

>> One possible action here would be to disallow sync APIs in shared
>> workers for now. This way we can use dedicated workers as a test bed
>> to see if sync APIs are a problem, and if they are, if that problem
>> can be fixed.
>
> This will just make people proxy messages from the shared worker to a
> dedicated worker, so nothing would change.  I don't think making shared
> workers more different from dedicated workers than they have to be makes
> much sense.

"People can already do things the wrong way" is a terrible argument
for introducing more ways of doing it the wrong way. The same argument
could be used to say that we should add sync IO APIs on the main
thread. It's already the case that you can write pages whose UI
doesn't respond until you get a result back from a worker or an async
IO operation.

/ Jonas

Received on Friday, 22 November 2013 17:56:45 UTC