[dmd-concurrency] Sending mesages to non-listening threads

[Andrei Alexandrescu]

Michel Fortin wrote:
> Le 2010-01-13 à 10:13, Sean Kelly a écrit :
>> On Jan 12, 2010, at 8:49 PM, Robert Jacques wrote:
>>> In think that a lot of of the need for this in Erlang is satisfied by having ultra-lightweight processes and its particular language niche. Erlang processes often have the same 'heft' as classes do in other languages. So, in terms of granularity, Erlang supports one mailbox per class, which is a lot finer than one per thread. As for use cases, one is CSP. Or one mailbox per client session on a server. Or one mailbox per GUI element. Or a master thread having one mailbox per worker. In the end, it's all about encapsulation, composition and compatibility. Yes, I can build all this functionality on top of send/receive, but then I end up with a giant muxing/de-muxing switch statement. This breaks encapsulation and makes it harder to maintain code. But worse, it prevents me from mixing two different libraries together, since they both use their own message formats, etc. With separate mailboxes, I can give each library their own communication channel and avoid those issues. Als
o!
>>> , since the API is supposed to allow the free interchange of thread mailboxes with network mailboxes, I assume non-thread-base mailboxes would be fairly simple to include.
>> All good points.  Sounds like we should at least provide the option to create ad-hoc mailboxes.  The only weird bit about multiple mailboxes per thread is that if one does a blocking wait for a message it could suspend the entire thread.
> 
> Why is it a problem? There's already many blocking calls you can make in any thread: you could open a file, make an HTTP request over the network, read from standard input or wait for a network packet. How is all this different from waiting on a message box? Should we prevent all of this from blocking a thread?

The difference is that waiting on the wrong mailbox could block you forever.

>> I guess this is even more reason to consider using fibers as the real return type of spawn(), though I guess GUI programs might not use spawn() at all?
> 
> How would that work?
> 
> I'm not sure why GUI programs would not use spawn to create threads, but surely GUI programs shouldn't use receive(), otherwise it'd block the GUI event loop.
> 
> GUI frameworks already have their own message passing system (for events), and their own event loops. Could there be a way to attach a customized "passer" function which would make the sending thread pass messages in a special way? This could allow messages to be sent to GUI threads by wrapping them in a GUI event. It'd simplify things from the worker thread point of view, which wouldn't have to mess with GUI stuff.

A GUI might have a different thread that calls receive() in a loop, 
converts messages to GUI events, and PostMessage() them to the GUI.

I wouldn't want to complicate things in not-experimented ways. If Erlang 
didn't need "passers" in 25 years, I guess there wasn't an overwhelming 
need for them.


Andrei