std.concurrency.receive() and event demultiplexer

[Ruslan Mullakhmetov]

Hi,

I'm playing around with std.concurrency and found it quite 
interesting. I drop all praise words (they all already said) and 
go to the question itself.

With std.concurrency we could have a number of asynchronously 
operating routines doing job "linearly", for instance, reading 
from socket and sending received data to consumer thread. that 
ok. but what if socket or generally handling task blocks 
indefinitely? We lose ability to respond to external world (other 
threads). Okay, we could employ async event-based model for 
handling our task (reading socket), but now we would block in 
event demultiplexer loop.

Now we could go further and overcome it with complication of 
logic:
   - timed wait for event on socket
   - when timeout occur check receive for incoming messages again 
with timeout
   - switch back to events waiting

The drawbacks are obvious:
   - complicated logic
   - artificial switching between two demultiplexers: event loop 
and std.concurrency.receive()
   - need to choose good timeout to meet both: responsiveness and 
cpu load

Alternatively it is possible to take away all blocking operations 
to another child thread, but this does not eliminate problem of 
resource freeing. with socket example this is dangerous with 
hanging socket descriptor and (1) not telling peer socket to shut 
up conversation (2) overflow of number of open file descriptors

The problem would be solved quite elegant if either (1) receive() 
could handle different events, not just communication messages, 
(2) it would be possible to get waitable descriptor for receive() 
that could be registered in 3-party event demultiplexer.

Of course receive() is not aimed for (1) and i know no ways to 
get (2) working.

So the question: how to overcome the problem i described if i 
described it clear.