Re: Sync IO APIs in Shared Workers

On Fri, Nov 22, 2013 at 11:55 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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?
>

If starting a worker is so expensive that this this is a real problem, that
seems like a bug.  If somebody is arguing that we should add a new API
because creating a new worker is slow, then that's an optimization
argument, and the burden of proof is on the claim that we need an
optimization, not that we never do.


> > 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.
>

I don't think they're comparable.  Spinning the event loop may have
unrelated, unexpected side-effects, since it'll run tasks from any event
source.  This wouldn't have any effects like that at all; it would just
check for messages on a specific MessagePort, and pop off and return the
first one.  It wouldn't pull a message from any port other than the one
you're working with.

>> 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.
>

I'm not convinced that synchronous work in shared workers *is* always "the
wrong way".  For example, sharing client-side autocomplete in a single
shared worker may be fine, since the user isn't going to be typing into two
tabs simultaneously.

And no, that's not the argument at all.  The argument is that this is
trivial to sidestep.  The lack of sync APIs on the UI thread is hard or
impossible to sidestep.

-- 
Glenn Maynard