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: tomasz jankowski (tomasz_jacek_at_[hidden])
Date: 2009-02-02 05:37:02

Dnia 2-02-2009 o godz. 10:08 Igor R napisał(a):
> >   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)

> 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/accept_timeout.cpp

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. 

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


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

tom



----------------------------------------------------
Człowieki, przystąpcie do konkursu !!!
Król Julian czeka na Was w Afryce - Klikajmy w ten link:
http://klik.wp.pl/?adr=http://bloog.pl/konkurs.html&sid=629