Thanks, First of all I made a typo in my own comments - the return parameter from boost::asio::poll is the number of handlers it did run (not one). According to spec it runs handlers that are ready to run, without blocking and I'm pretty sure it does what it says (Not blocking)
Second, it's a bit worrying (for me at least) that the libevent equivalent call does indeed block - Do you have any hints on when it's actually blocking? >(event_base_loop(_event_base, EVLOOP_NONBLOCK); Third, I also agrees on "and personally I don't think that it is sane to use two event loops in one application", BUT either I rewrite an existing (proprietary) proxy based on asio or an existing db client library (aerospike db) based on libevent. I'm thinking I might get away with handling the server code from asio and make polling calls to libevent queue in asio callbacks on events - both timer and io related ones but I'm looking for a cleaner solution. I've done the same for a libcurl based client in the past and it was possible to get to the sockets before libcurl actually waited for io. /svante
