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

Robert Jacques sandford at jhu.edu
Wed Jan 13 10:33:33 PST 2010


On Wed, 13 Jan 2010 12:41:32 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:
>>> 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

Erlang uses "passers" all the time. The difference is spinning off an  
Erlang process is no big deal, so you don't think about it. Spinning off  
an OS thread, on the other hand, is a big deal.

I was also thinking about OS/windowing implementors (i.e. Plan9) as D is a  
systems programming language. I think being able to write a windowing  
system is a major use case for D's concurrency system. Yes, it probably  
won't happen, but it will make sure we cover all our bases.


More information about the dmd-concurrency mailing list