On Tue, 27 Nov 2012 11:54:01 GMT, Sönke Ludwig wrote:

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.

Oh, I see. Now it makes sense why the sleep is a special case.

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.

I will have to use the runEventLoop(), a server will push information to a client from time to time.
If you say there are vibe-specific mutex and signal, then I can try to come up with some solution using these two. I will probably don't have a time until tomorrow, but I will try to report my progress for anyone interested. If you have any ideas that might help, feel free to throw them at me ;-)

Thanks,
Martin