Re: [Boost-users] Concurrency and session termination in boost::asio

Subject: Re: [Boost-users] Concurrency and session termination in boost::asio
From: Scott Gifford (sgifford_at_[hidden])
Date: 2008-11-07 17:43:28

"Igor R" <boost.lists_at_[hidden]> writes:

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