Hi Chris,

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

Wow. That doesn't make sense. It fails for me in 5 seconds or less. I'm running on a 2 CPU system, so that may make a difference.

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.)

I grabbed the code in boost CVS about 2 weeks ago. Should I get latest again?

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.

For the client, that's probably acceptable. But for the server we really need multiple threads. Is it okay for each thread to create it's own io_service to solve this problem?

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.

Well, the current client design works like this. The client is an MFC UI application. We spawn a background thread inside io_service::run() to handle incoming asynchronous communications. The server can send responses to the client at any time. In other words, the client might send a request to the server to monitor the CPU utilitization on the server. In that case, the server will send a CPU packet roughly every second with the current CPU value. The io_service thread would receive the packet, push the response into a callback queue and notify the MFC UI thread via a windows message that it has a waiting server response. In addition, the UI thread may, in response to some user action, make other synchronous requests for the user (on the same socket, which apparently is a bad idea?). Those synchronous requests are dispatched to the server. The reply is handled in the same manner (callback via windows message). So, if I understand correctly, the UI should *not* be using the socket class because we spawn a background thread to receive data on that socket? Thanks, Scott