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

[Sean Kelly]

On Jan 13, 2010, at 9:07 AM, Michel Fortin wrote:

> Le 2010-01-13 à 10:13, Sean Kelly a écrit :
>> 
>> 
>> 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?

Fair enough.

>> 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?

Multiplex fibers on kernel threads and yield inside the receive call.

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

Oops, you're right.

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

For GUI events, it's more likely that you'd have a thread waiting for those messages and then repackaging and resending them using the D model.  I've thought about trying to have some way to use a custom encoding layer, but haven't come up with a good solution yet.