On Tue, 27 Nov 2012 10:52:41 GMT, Martin Drasar wrote:

(...)

Regardless of readln being in separate thread, this code does not work without the sleep being uncommented.
Probably the `core.sync.Condition.wait() in receiveOnly() that uses pthread_cond_timedwait blocks the sending, while the nanosleep in sleep()` does not.

While reading in a separate thread would be a non-issue for me, this seems like a much bigger problem.

Ah no no, sleep is actually vibe.core.core.sleep and that will keep the event loop running. But you are right, any blocking operation that prohibits event processing will cause this behavior.

It could be worked around in a limited way (probably by not using libevent but directly the OS facilities), but generally blocking operations will always inhibit I/O, it's a property of the asynchronous model (*). There is vibe.core.core.signal.Signal that can be used to wait for other threads or tasks without blocking the event loop. std.concurrency cannot be used as is, it would have to use the fiber aware Signal and Mutex classes of vibe.d so that it doesn't interfere with it.

(*) assuming that the I/O is running inside a task/fiber. Would that actually be the case for you, or are you never calling runTask or runEventLoop in the client? If that's the case, it is probably possible to add some code for TcpConnection.flush() that waits until the data is actually delivered. But this would fail again as soon as tasks and the event loop are used.