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

[Sean Kelly]

On Jan 12, 2010, at 8:49 PM, Robert Jacques wrote:

> On Tue, 12 Jan 2010 20:55:09 -0500, Andrei Alexandrescu <andrei at erdani.com> wrote:
>> 
>> 
>> Good question. I had been thinking about it; in particular, that means the built-in mailbox is just a hidden global. I haven't been able to think of compelling scenarios though, and Erlang doesn't seem to need them.
> 
> 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. Also, 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.  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?

> With regard to CSP, although there are some high-level things which can be left for after TDPL and built on top of other primitives, some things, like mailbox state (closed, last message, poisoned, blackhole) and alternatives/selects seem like very useful low level primitives which could be included efficiently.

I definitely want it to be possible for CSP to be layered on top of this package, so if there's something we need to add for this to happen, we will.  Linking of threads, for example, will definitely happen.  It may be that some things aren't practical to integrate directly though, and would have to be handled at the protocol level by such a package.  It's been a while since I looked at CSP in detail, so if you have any suggestions here they'd be very welcome.