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:

 

 

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