Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-09 13:45:02

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > > 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)

I've not included a return type currently.  That's something that's 
open for debate, but I find that most of the time it's not an integer 
return that you need, so the whole C based concept of returning an 
integer is flawed and serves little purpose.  But that's *MY* opinion 
and I'm more than willing to listen to arguments on this one.

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

Your final wording after the "--" is the rub here.  Both pthread_join
() and pthread_detach() invalidate the thread object.  The goal of 
Boost.Threads was to not do this... the thread object would be valid 
until it's destructor is called.  I'm concerned I don't have this 
right for POSIX yet, though.
 
> > > 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 was talking conceptually, not technically.  After the first call to 
join() the thread has been fully terminated and cleaned up.  Any 
subsequent call will attempt to do the same thing, but find there's 
nothing to do.  You can't clean up twice ;).
 
> > 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.

I don't totally follow you here.  I don't see why there's a need for 
two differing semantics.  When would it ever be valid to wait for the 
thread to "begin termination".

Bill Kempf