Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-13 04:23:21


> > > 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've stayed out of this so far, but... Bill is ABSOLUTELY right here,
and
> the semantics don't change - in all cases the call will wait until the
> thread has finished and then clean up resources -

that is what i was asking for.. subsequent calls should be
synchronized with the initial "join" library call; subsequent
calls should block until initial "join" library call returns.

> if that has happened
> already then there is nothing to do - there's no problem with that even
if
> it is different from the way POSIX does things, and it's infinitely more
> useful IMO.
>
> >thread::wait_for_term( bool term_completed=true ) or
> >thread::wait_for_term( bool join=true ) or
> >thread::wait_for_term( bool blablabla=true )
>
> That would be appalling, sorry. How do you know if a thread has been
> joined already (by some other thread)?

if you mean "join" == native thread object cleanup only; you do not
really need to know it.. you just need to code (explicit or implicit)
destruction of your C++ thread object (for joinable/non-detached threads).
it could be done for you "automatically" (if not already done "manually")
on the C++ thread object destruction (by C++ thread object itself).

regards,
alexander.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk