Re: Redesigned thread class

From: williamkempf_at_[hidden]
Date: 2001-08-21 13:02:31

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > From:  williamkempf_at_h...
> [...]
> > > Please verify something for me.  Alexander quoted Dave
> > > Butenhof as saying:
> > >
> > >  > But there were two problems. [1] There was no way to alter 
the
> > >  > initial thread of a process so that its resources would be
> > >  > automatically reclaimed on termination. [2] And there was 
this
> > >  > nasty problem in join; where, if the join is cancelled,
> > >  > which implies it didn't complete, the target thread of the
> > >  > join would languish forever -- another memory leak about
> > >  > which the program could do nothing.
> > >
> > > Is it correct that your design does not have either of these
> > > problems because C++ semantics take care of [1], and [2]
> > > can't happen because there is no join cancellation?
> >
> > I don't understand [1]...
> 
> e.g. (your CV example from condition.html):
> 
> >> int main(int, char*[])
> >> {
> >>     boost::thread::create(&sender, 0);
> >>     boost::thread::create(&receiver, 0);
> >>     boost::thread::join_all();
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>     return 0;
> >> }
> 
> the other way (probably better way, IMHO) could be
> (if you would support pthread_detach/exit):
> 
> int main(int, char*[])
> {
>     boost::thread::create(&sender, 0);
>     boost::thread::create(&receiver, 0);
> //     boost::thread::join_all();
>     boost::thread::<...current_thread...>detach();
>     boost::thread::<...current_thread...>exit();
>     // should never reach this point
>     return 0;
> }
> 
> news:Y76g7.322$bB1.27349_at_n...
> 
> David Butenhof wrote:
> 
> "POSIX allows you to terminate the initial ("Main") thread
>  by calling pthread_exit(), or by cancelling it. In either
>  case, the process will continue running, but no implementation
>  resources owned by the initial thread will be reclaimed,
>  unless the initial thread has been detached or some other
>  thread later joins with it. (Under normal circumstances, no
>  thread will have the pthread_t of the initial thread; but it
>  does have one, and it can get it, and save it somewhere so
>  another thread can find it.) Usually that's not a big deal,
>  since there's only one initial thread. Still, there ARE
>  resources, and they MAY be stranded, and if that's an
>  issue, you need to consider the consequences."
> 
> POSIX:
> 
> "void pthread_exit(void * value_ptr);
>  ...
>  The process shall exit with an exit status of 0 after
>  the last thread has been terminated. The behavior shall
>  be as if the implementation called exit() with a zero
>  argument at thread termination time."

Hmm... I was not aware that POSIX operated this way.  Seems to me 
that this means the pthreads-win32 isn't compliant (unless they found 
some way to work around this).  The main thread on Win32 is 
synonymous with the process and if you exit the process all threads 
are terminated.  I'm not sure what Boost.Threads will do in this 
regard if/when we add thread::exit().

Bill Kempf