[whatwg] Workers feedback

[Ian Hickson]

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

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.   `._.-(,_..'--(,_..'`-.;.'