You know, io_service must be run for accepting.

Again - io_service must be running for *asynchronous* accepting (async_accept), but if you use syncronous accept() then you never explicitly run io_service. See the following example: http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/echo/blocki...

don't we have to do it in such way?

acceptor_(io_service_) acceptor_.bind acceptor_.listen acceptor_.async_accept io_service_.run

You mixed here blocking and asyncronous calls (which is legitimate), and since asyncronous calls present in your code someone must process them - that's exactly what io_service::run does, and that's why you must call io_service_run() (please note that io_service.run() is blocking call, meaning that it wouldn't return before all pending work is done). But if you would stick with blocking calls only, you wouldn't have to run io_service: acceptor_(io_service_) acceptor_.bind acceptor_.listen acceptor_.accept // not async_accept! // do something with the accepted socket...

...

Note that it is an async. implementation for *synchronous* use, and when you use sync. i/o you do not explicitly run io_service: io_service io; tcp::socket sock(io); // open socket, define your buffer..., then: read_with_timeout(sock, buffer); I don't understend. what is synchronous here? could You explain Igor? "Synchronous" (or blocking) means that a function call completes ("returns") only after its job is done. In our case read_with_timeout blocks until the data is read or the timeout occurs. Asynchronous version would return immediately, and when the desired event occurs, it would notify you by means of the completion handler that you supply.

...

But if you've already got an async. design, you don't need workarounds to implement timeouts - just use deadline_timer in the straightforward way. it's mean - how? which example shows it?

Please, look at this exmaple (it's very simple and demonstrates exactly what you need): http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/timeouts/ac...

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

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

AMDG Chandra Kumar wrote:

Though I have not checked rigorously right within the boost, but wanted to get quick answer to the query below:

“Do we have the complete implementation of the C++0x language feature: “*concepts*”: within boost ?

No. Concepts really are a language feature, not a library feature. C++03 emulation for concepts is very imperfect (and has significantly different syntax).

Actually, conceptgcc is very slow compared to gcc, so I was looking for quick solution in order to use concepts in its entirety.

In Christ, Steven Watanabe