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.
