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
> > 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...
> > 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
> 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.
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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk