Re: boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-03 05:21:19

> > 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 exits
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.

"The pthread_exit( ) function shall terminate the calling thread
 and make the value value_ptr available to any successful join
 with the terminating thread. Any cancelation cleanup handlers
 that have been pushed and not yet popped shall be popped in the
 reverse order that they were pushed and then executed. After all
 cancelation cleanup handlers have been executed, if the
 thread has any thread-specific data, appropriate destructor
 functions shall be called in an unspecified order. Thread
 termination does not release any application visible process
 resources, including, but not limited to, mutexes and file
 descriptors, nor does it perform any process-level cleanup actions,
 including, but not limited to, calling any atexit ( ) routines that
 may exist. An implicit call to pthread_exit() is made when a thread
 other than the thread in which main() was first invoked returns from
 the start routine that was used to create it. The function's return
 value shall serve as the thread's exit status."

> 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.

regards,
alexander.