views:

69

answers:

0

Another one in the continuing saga of myself vs. Boost.Asio...

I have a simple asynchronous client and server that utilise async_write and async_read to communicate. The client can successfully write bytes to the socket, but the server never sees them; my read handler on the server fails with "Operation cancelled".

I'm inclined to believe that this may be a timing issue with the client writing the data after the server has tried to read it and failed, but I would have thought the data would be waiting on the socket anyway (unless the socket has been closed in the meantime).

To test this I simply re-ran the read operation in the error handler, i.e.

read_handler()
{
    if (!error) {
        /* bytes read */
    } else {
        async_read(socket, buffer, read_handler)
    }
}

But all this got me was a segfault in pthread_mutex_lock via a call to async_receive.

Could anyone point me in the direction of any relevant information (or, better yet, tell me exactly what I'm doing wrong ;) )?

UPDATE: The server and client are based around the chat server example in the Asio docs, with the client and server both running under the same process (could this be an issue? Thinking a bit more they both use the same io_service...); both asynchronous and using Boost 1.44.0. I'm working on OS X but this is reproducible on Linux, too.

UPDATE II: My hunch was correct and if the server and client are given separate io_service objects the async_read sees the bytes on the socket. This does still give a segfault in boost::asio::detail::kqueue_reactor::post_immediate_completion that seems to stem from the io_service.run(). Before I go any further, is using separate io_service objects the correct approach?