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
> > > 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
> > > 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...
> > > 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
> > other words, you should not rely on the reader to know the
> > term "join" in the description.
> > I think it's ok to use a technical term, but we have now
> > 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.
> 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
> 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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk