Date: 2001-08-03 08:34:34
--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > > Thanks, got it. I've been perusing the source quite intently
> > so far I
> > > really like what I see. I also have a question. I have an
> > application that
> > > creates several threads and I want the main thread to be able to
> > find out if
> > > any of the created threads have died. It appears that I could
> > this using
> > > boost::thread::try_join() on each of the created threads, but is
> > there (or
> > > will there be) a better way? Currently, the app is using
> > > WaitForMultipleObjects() to do this.
> > The Wait* operations in Win32 threading are both extremely nice,
> > a major pain. Boost.Threads doesn't directly support any concepts
> > similar to WaitForMultipleObjects (other than
> > thread_group::join_all). However, it's not difficult to do what
> > want here using a condition variable, though this requires support
> > from the threads which will have to notify_one/all() the
> Yes, I'm also considering this. It will work as long as the thread
> some "normal" means, which it always should (i.e., by returning
> thread function, not because something called
> _endthreadex/pthread_exit/etc). I just thought it would be a bit
> robust if I could also get asynchronous notification in all cases.
I've considered including a thread::exit() routine, but don't expect
one in the first release. For now, calling such native methods would
produce undefined behavior.
> > > I realize that this is probably just an optimization, but it
> > strange
> > > to have to poll to find out if a thread has ended.
> > Are you _trying_ to find out if a thread has ended, or waiting
> > any thread has ended? In other words, is the wait a blocking
> > operation?
> Right now it checks (polls) periodically to see if any have ended.
> considering what the implications would be if I changed it to wait
> until any thread ended.
Just curious, but what does it do if the poll indicates a thread has
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk