From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-11-08 16:14:07
Chris Richards <chris.richards_at_[hidden]> wrote:
> What happens is that the expection is caught in one thread,
> and that thread exits gracefully, but also the handler for the
> async_accpet is called with an error stating "The I/O
> operation has been aborted because of either a thread exit or
> an application request.", causing that thread to exit as well.
Yep, that's the way it works on Windows. Overlapped I/O
operations are tied to the thread that starts them, and so if
that thread exits the operations are cancelled. The effect of
thread-exit on asynchronous operations is deliberately specified
as "implementation-defined" in asio for this reason.
For portability you'll probably have to look at a different way
of structuring it, e.g. an io_service with a fixed sized pool
for handling I/O operations, plus an additional io_service with
a variable pool for handling CPU intensive tasks.
BTW, in CVS the io_service now has member functions run_one(),
poll() and poll_one() in addition to run(). These might offer
you an alternative way of controlling how many threads are in
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk