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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-09 05:41:40

> > As far as naming goes, my main problem is with the terms "join" and
> > "detach".
>
> For what it's worth, I haven't used pthreads, and when I read the docs
> for the Boost.thread stuff I was wondering where "join" came from. It
> does not make much sense to me either. It left me with a very strange
> picture where two threads were somehow merged into one, which I don't
> feel is approprate. What you do is you stop one thread until another
> ends. So the current thread is waiting for the other to stop. It's not
> joining anything.
>
> So, I agree that wait is better than join.
>
> Similary,
>
> join_all -> wait_all.
>
> try_join -> is_running.
>
> timed_join -> timed_wait.
>
> I realize that you use the term "wait" for the conditions, but I don't
> think that this will lead to confusion.

pthread C _join is *NOT* equal to win32 Wait... what it does
in terms of win32 API is the following:

WaitForSingleObject( hThread,INFINITE );
GetExitCodeThread( hThread,&dwExitCode );
CloseHandle( hThread );

in pthread only one thread could call _join and it could
do _join only ONCE. now, in terms of some C++ thread
library (e.g. Boost.Thread) it might become possibly to
call somethread.join() on multiple threads and continue to
do "join" calls as long  as that C++ thread object exist
(C++ thread object would properly synchronize these calls
and would call native _join only once) nevertheless at
least one thread would perform REAL join and others would
have to wait for it to occur. so, i believe that _join is
still a better name here even for C++ thread object which
could outlive "native" thread object <- get destroyed by
"first" (and the only one) native join call.

regards,
alexander.