Hi Scott, I was about to write to say that I ran your previous test program for about half an hour without any problems.

I started thinking about my own client code and read up on the socket class. The docs say the socket object is unsafe for shared objects. So I put locks around every async_read or async_write operation. However, it still fails.

Is the problem with my code the fact that 2 threads are using the same socket?

Yes, that is a problem. I don't know if it is *the* problem.

Is that just not possible?

Rather than using a mutex, a better approach would be to use an asio::strand object. You can use a strand to wrap your handlers and they won't be executed concurrently (see the last timer tutorial for an example). A mutex will *not* give the correct behaviour in the case of "composed" operations like boost::asio::async_write. (Note: i'm assuming you're using the latest code in CVS here.) However, I am not confident that the current SSL wrapper implementation is thread safe even if you use a strand. It may simply be safer at this time to stick to using an individual SSL object from a single thread. In practice that means only calling io_service::run() from a single thread. What exactly is it that you want to do with the second thread? There may be another way of structuring it to give the same effect while keeping all access to the ssl/socket object from the one thread. Cheers, Chris