Re: [Boost-users] Thread_group semantics

Subject: Re: [Boost-users] Thread_group semantics
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-01-14 02:23:02

On 14/01/2014 14:05, Quoth Kenneth Adam Miller:
> Yeah, but I want to be able to create a thread_pool in the creating
> thread and then move on, posting work to it whenever. In your shutdown
> descriptions for the first way to do it, you seem to describe no way to
> make sure that all work posted to it gets completed.

Read 5b in the first method again.

Basically the thread pool stays alive (and cannot be joined without 
blocking) as long as there is any outstanding work, and nobody has 
called stop() yet (and calling stop will potentially abandon queued but 
not yet started work).

If there will be a time that you do not have any "real" work queued to 
the io_service, then you must create an io_service::work object to act 
as "fake" work that keeps the threads alive.

But consequently, if you try to join the thread_group while that work 
object still exists, the joins will block indefinitely.  So you need to 
keep the work object alive for as long as you want to be able to queue 
additional work to the service, and destroy it prior to joining while 
shutting down the service.

Note that you still might need to do other things to achieve a clean 
shutdown, such as cancelling pending operations or setting flags to 
prevent a completed operation from queuing additional operations.  (For 
example, with I/O it's common to have the read/write completed callback 
post the next read/write request, and you probably don't want to do that 
sort of thing while you're trying to shut down.)