"Igor R"
Also I was planning on having my read callback handle some commands that may be slow, such as database queries, and I didn't want all other clients in the same io_service to block while that's happening.
[...]
Anyway, all these tricks aim to simplify the design by minimizing multithreading mess. Afterall, if you see that it just complicates your design, you always can prefer spreading locks in your code :).
Yeah, I don't mind using locks, but I'm not exactly sure which boost::asio operations require locks for concurrent access, and which do not. Maybe I'm trying to make things more complicated than they are, and it's simply the case that *all* concurrent access to the same boost::asio object requires a lock to be held? I had been assuming that it's safe to make concurrent calls to a tcp::socket's async_read() and async_write() methods, is that a correct assumption? Or do I need to hold a mutex whenever I'm calling any method on a tcp::socket? Looking more closely at the documentation, it looks like that's the case. The only example I found with a thread pool was HTTP server example 3, and HTTP never needs to deal with simultaneous reads and writes. If anybody knows of any examples floating around that do simultaneous reads and writes with a thread pool, I would very much appreciate a link.
If the client session is cancel()ed or close()d, does that clear out the callback queue of anything related to that session? Or do I need to be aware of the possibility that the session is now closed()d somehow?
If you close() a socket, the callback queue is certainly *not* cleared, because such a clearing would violate very important guarantee provided by asio: every async. request ends up calling its handler (probably with some error passed to it). Number of landings should be equal to the number of takeoffs - that's what allows us, in particular, to use that automatic lifetime management by binding shared_ptr to the handler.
Ah, I see, makes perfect sense, thanks for the explanation! Thanks again for all your help, both Igor and Boris! -----Scott.