RE: [boost] Re: Threads docs updated in CVS

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-09 13:20:45

> > No, there still is the issue of cleanup.  When boost::thread::join()
> > is called it does not return until the thread of execution is
> > finished, it's stack reclaimed and any cleanup handlers called.

ok. great! that is exactly posix "join" type of synch. operation.
(in addition, tsd destructors should be called after cleanup
handlers and then *after thread of execution is finished*
(at least with respect to application code/data/stack) join
should return thread start routine return value or thread
exit() argument or some special value/indication of thread
been cancelled)

> > The only difference is that Boost.Threads, like Win32, treats the
> > thread object as a seperate entity from the thread of execution.

pthreads do the same.. for non-detached thread its internal
thread object (represented by pthread_t thread id) exists
even after thread termination -- until pthread_join() or
pthread_detach() is called.

"A conforming implementation is free to reuse a thread ID
 after the thread terminates if it was created with the
 detachstate attribute set to PTHREAD_CREATE_DETACHED or
 if pthread_detach() or pthread_join ( ) has been called
 for that thread. If a thread is detached, its thread ID
 is invalid for use as an argument in a call to
 pthread_detach() or pthread_join()."

"If the thread is created detached, then use of the ID of
 the newly created thread by the pthread_detach() or
 pthread_join() function is an error."

"The pthread_join() or pthread_detach() functions should
 eventually be called for every thread that is created so
 that storage associated with the thread may be reclaimed."

"It is unspecified whether a thread that has exited but
 remains unjoined counts against _PTHREAD_THREADS_MAX."

> > Calling join() multiple times on this object is valid...

ok.

> > any call made after the first simply exits immediately since all
> > the cleanup has already been handled during the first call.

NOT OK! (unless you have made it atomic, which i doubt) here you
introduce different semantics for subsequent calls (could be done
from different thread(s)). it should provide the same behavior
(wait until term. is completed) in all cases (for all joining
threads), IMHO.

> I think you should add this surprise to the documentation of join. In
> other words, you should not rely on the reader to know the technical
> term "join" in the description.
> I think it's ok to use a technical term, but we have now established
> that it's not a well-known term to some users, including me.

how about something like:

thread::wait_for_term( bool term_completed=true ) or
thread::wait_for_term( bool join=true )           or
thread::wait_for_term( bool blablabla=true )
                            ^^^^^^^^^
                            technically means JOIN.
                            on return, thread term.
                            is completed.
-or-

thread::wait_for_term( bool term_begin_only=false ) or
thread::wait_for_term( bool no_join=false )         or
thread::wait_for_term( bool blablabla=false )
                            ^^^^^^^^^
                            technically does not mean JOIN;
                            simply begin of thread term.
                            does not guarantee that term.
                            is completed on return.

-or-

just provide two sets of functions:

thread::join() and thread::wait_blabla()
^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^
   *JOIN*          wait for begin of
multiple calls     thread termination,
(from multiple     does not guarantee
threads) is OK.    that term. is completed
                   on return.
regards,
alexander.