[whatwg] Workers feedback
ian at hixie.ch
Mon Dec 15 21:33:19 PST 2008
On Tue, 18 Nov 2008, Alexey Proskuryakov wrote:
> > [...] If you implement the actual IPC using, say, a Unix socket, then
> > you can just pass the actual socket along and do the same thing
> > without blocking.
> This is an interesting point. I do not know enough about how Unix domain
> sockets are passed around, but since they the laws of nature are the same
> for them, it's either that:
> - my FUD is unbased, and it is in fact possible to implement the behavior;
> - or semantics are very different for sockets. Some guesses are that queues
> may be strictly limited in size, message delivery may not be guaranteed, or
> that it is possible for client code to irrepairably deadlock processes with
> them - something that JS developers obviously shouldn't be able to do.
> I do not know which of the options is correct, but if the spec talked in
> terms of message passing, it would have been more easily verifiable.
I've revamped several parts of the spec today, so it may be that this is
better now. I imagine that your original problem didn't go away, since I
still talk about entangling things synchronously, but as far as I can tell
there's not any way to actually distinguish what the spec describes from a
more asynchronous message-passing mechanism, so long as you have an
implementation strategy that handles the queuing of messages in the
message channels separately from the passing of ports to other threads.
> > If you mean that two ports in two threads are posted to each other's
> > threads at the same time,
> Yes, this is what I'm talking about.
> > then deadlock would only happen in a naive implementation that didn't
> > keep pumping its message queue while waiting for a response from the
> > other thread. Instead what you would want to do is to ask for a
> > semaphore to communicate with the other thread, and if you don't get
> > it, see if anyone wants to communicate with you, and if they do, let
> > them do whatever they want, and then try again.
> Designs like this are quite prone to all sorts of crazy problems, too.
> As a simple example, the port waiting to be entangled may be sent
> further on, if you let them "do whatever they want".
If you're using one of the mechanisms I outlined in my e-mail to Jonas
earlier today, as far as I can tell you end up sidestepping these issues.
> > I'm certainly open to changing the algorithms around if a better
> > solution exists in a manner that gets the same behavior. I'm certainly
> > no expert on the topic (as I'm sure the above responses have shown).
> Since the spec is written in form of algorithms, and relies on a number
> of arguable implicit assumptions on the implementation of their steps,
> it is hard to process or verify the algorithms. In my opinion (I'm not
> claiming expertise either!), a message passing design would be much
It's not clear to me how the current design _isn't_ a message-passing
design. The only way to get a port into another thread is to post it over
a previously created channel, which is message passing.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg