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

[Robert Jacques]

On Tue, 12 Jan 2010 20:55:09 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:
> Robert Jacques wrote:
>> On Tue, 12 Jan 2010 17:27:09 -0500, Andrei Alexandrescu  
>> <andrei at erdani.com> wrote:
>>> Sean Kelly wrote:
>>>> There are a bunch of things still missing from the current API that  
>>>> will need to be addressed at some point though, like linking threads  
>>>> (so one will be notified if the other exits), a Tid registery, and  
>>>> probably a bunch of other things I'm forgetting offhand.  These  
>>>> aren't necessary for a first cut, but they'll have to be added soon  
>>>> after.
>>>
>>> Yah, please do mention everything you remember. I want to describe a  
>>> reasonably complete API.
>>>
>>> Andrei
>>> _______________________________________________
>>> dmd-concurrency mailing list
>>> dmd-concurrency at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>>  On that note, will we be able to create message boxes/queues that are  
>> separate from threads?
>
> 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.
>
> Andrei

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.

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.