Date: 2001-08-02 17:21:13
--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > --- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > > I'd like to read the documentation/proposal for Boost.Threads
> > source, or
> > > any description)--where can I find it? The archives indicate
> > at one
> > > time there was a file in the threads directory on yahoo called
> > threads2.zip,
> > > but it is gone, and there doesn't seem to be anything in CVS
> > It does exist in CVS, but on a branch instead of part of the main
> > distribution. Check out the branch threads-initial. Note,
> > that the code and documentation are both currently under frequent
> > extensive modifications in preperation of formal submission.
> > Bill Kempf
> Thanks, got it. I've been perusing the source quite intently and
so far I
> really like what I see. I also have a question. I have an
> 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 do
> boost::thread::try_join() on each of the created threads, but is
> 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, and
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 you
want here using a condition variable, though this requires support
from the threads which will have to notify_one/all() the condition.
> I realize that this is probably just an optimization, but it feels
> 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 until
any thread has ended? In other words, is the wait a blocking
> P.S.-- I also spotted an apparent infinite loop in the code:
> bool thread::operator!=(const thread& other) const
> return operator!=(other);
> That should be !operator==(other), no?
Oops. Yep. Nasty typo on my part. Thanks for catching that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk