Boost logo

Boost :

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-08-03 08:57:20

----- Original Message -----
From: "Alexander Terekhov" <terekhov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 03, 2001 5:21 AM
Subject: Re: boost.threads [was RE: [boost] Re: sockets /network programming

> > > 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.
> > >
> >
> > Yes, I'm also considering this. It will work as long as the thread
> by
> > some "normal" means, which it always should (i.e., by returning from the
> > thread function, not because something called
> > _endthreadex/pthread_exit/etc).
> returning from the thread function has the same affect as calling
> pthread_exit.

Yes, I know. I just meant that I wanted to signal the condition variable in
only one place if possible, rather than at every call to

> > I just thought it would be a bit more
> > robust if I could also get asynchronous notification in all cases.
> you can easily build robust notification mechanism via
> incorporating the code in some cancellation cleanup handler
> (and using pthread_cleanup_pop() with a non-zero "execute"
> argument) or doing it in some thread specific data destructor.
> the difference with respect to windows model is that that
> notification mechanism is not a part of any thread; it is
> some extra monitor (shared data protected by mutex and CV(s)
> used to wait for state(s) changes). windows uses thread handle
> replication mechanism which is "simple" but is really an
> overkill, IMHO.

Thanks for the suggestions; I may end up doing something like this. I was
just looking for a portable way, since I need to support windows and linux.

Boost list run by bdawes at, gregod at, cpdaniel at, john at