After having an interesting discussion with Brendan on the topic of deadlocks in threaded and asynchronous event handling systems (see the comments on this blog post), I just had something to ask to the developers on OSnews: could you live without blocking API calls? Could you work with APIs where lengthy tasks like writing to a file, sending a signal, doing network I/O, etc is done in a nonblocking fashion, with only callbacks as a mechanism to return results and notify your software when an operation is done?

I have already worked with some systems implemented that way. In the first moment they seem weird and it takes some time to get used to them, but afterwards it start to make sense. One advantage is that it seems to be easier to identify performance bottlenecks (you will end up having a queue of pending operations, so you can easily monitor these queues and apply all math from queueing theory classes).

Other day I stumbled upon ZeroMQ, which uses a kind of mixed approach. All writes/TX is async (queued and handled by a background thread) and read/RX may be sync or async, depending on configuration.