|
Boost : |
From: Rod Morison (rod_at_[hidden])
Date: 2006-08-17 19:41:12
I'm studying the async daytime server example, Daytime.3 (0.3.7
flavor):
http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/tutorial/tutdaytime3src.html
(I'm doing an Asio proof/concept for an app that has to dynamically
change it's service ports.)
I'm trying to think through how to perform a clean shutdown in this
example. There could be a number of pending async_write()'s, each with
their own socket and uncalled handler. There is probably also a socket
waiting on the async_accept() with an an uncalled handler.
Questions:
- With the work pending, io_service will need to call it's interrupt()
function (from another thread) to stop processing, correct?
- If io_service is destroyed, what happens to the otherwise pending
work, i.e., the async_write's and async_accepts that it controls? What
about the socket resources?
- I can close the tcp::acceptor in tcp_server, but what about the
socket that's listening on it?
- If Asio doesn't release system handles, e.g., sockets, how do I get
at the resources to clean up?
- Is there an example of a resource clean shutdown? I skimmed the
example apps and didn't see one first pass.
Thanks,
Rod
-
If the io_service is destroyed, what
Is there a way to do this with the io_service?
In a watchdog thread...
-call io_service.interrupt() to stop processing
-tell the tcp_server to
The io_service.run() won't exit until all services and handlers are
finished. Let me take a stab at a shutdown design and perhaps Asio
vets would be willing to tear it apart/fix it?
This assumes the Daytime.3 server code at
http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/tutorial/tutdaytime3src.html
(I noticed the 0.3.6 example is somewhat different.)
in tcp_server
-------------
- add a cleanup() method that calls acceptor_.close()
in main()
---------
- add a watchdog thread that will shutdown the server's io_service
- if shutdown time then
How do I notify handlers
io_service.dispatch() or io_service.post() to wake up handlers
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk