Re: [Boost-users] [boost-users][asio] timeout -isio_service.reset() safe with pool of threads?

Subject: Re: [Boost-users] [boost-users][asio] timeout -isio_service.reset() safe with pool of threads?
From: Igor R (boost.lists_at_[hidden])
Date: 2009-02-02 06:33:51

>
>       acceptor_(io_service_)
>>   acceptor_.bind
>>   acceptor_.listen
>>   acceptor_.async_accept
>>   io_service_.run
>>
>
> You mixed here blocking and asyncronous calls (which is legitimate),
>
>
>
> so, how 'pure' async_accept should looks than? (without mixing)

I'm sorry, I just missread your code - you don't mix anything there, you
just set-up the acceptor and launch asynchronous accept.

>  at last I understood how io_service works.
> till now I thought "why they are talking that I have to schedule async
> operation first than run io_service.
> in server example there is async_accept and io_service.run() and server is
> accepting forever. So, run() must running forever. ". I did not caught that
> in async_accept handler there is once again async_accept. this trick don't
> let run() never end.
>

Exaclty. If you look at other asio examples you'll see the same pattern:
async. operations are chained in the way that completion handler of a
previous operation launches the next one. This pattern allows you to end the
i/o in a very simple way: just break the above chain and the
io_service.run() ends. Note also that if your handlers are made of some
"connection" object (using shared_from_this, like in the examples) that
encapsulates socket, then when the chain terminates, this object is
automatically destroyed closing its socket.
However, such a simple design is not always possible. In more complicated
cases you have to keep io_service running *always*, even when there's no i/o
activity - until explicitly stopped. Refer to the following example to see
how you can do this:
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/http/server2/io_service_pool.cpp

>  It seems that I understand now what does it mean : explicitly/implicitly
> run io_service, synchronous/*synchronous*
>

In a synchornous (blocking) design you cannot run io_service "message loop"
(which would block itself), so blocking functions pump their io_service by
themselvs, in their implementations.

> once again thanks for your efforts (in sharing asio knowledge) Igor

you're welcome :)