From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-07 13:22:01
----- Original Message -----
From: "Iain K.Hanson" <iain.hanson_at_[hidden]>
> -----Original Message-----
> [mailto:boost-bounces_at_[hidden]]On Behalf Of William E. Kempf
> Sent: 07 August 2002 17:05
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Threads & Exceptions
> >Possibly. Ignoring the issues of the main thread, this is behavior that
> >could be trivially implemented in Boost.Threads (in fact, that's the way
> >works today because of a bug). However, this allows exceptions to be
> >with no way for the program to detect them. I think it's much more
> >appropriate for this to result in a call to terminate(), which removes
> >issues of the main thread being different, and requires no language
> >to support this.
> If I remember correctly, pthreads says that if the main thread exits while
> other threads are running then the process exits whether they like it or
You remember almost correctly. If main exits in the normal fashion then
yes, this is precisely what happens. If you exit the main thread by a call
to pthread_exit(), however, the main thread terminates but all other threads
continue and the process remains alive. All platforms I'm familiar with
follow this same sort of concept.
> I don't see this as being a
> big problem although it would be nice if a thread could be told, so that
> could clean up.
> ( not all resources are cleaned up when a process terminates. )
That's what exit handlers are for.
> Could the exception that caused a thread to die not be stored in the
> class? That
> would allow detection if it was desired.
That's back to the argument of passing exceptions, and the argument against
is that it's very possible the polling function(s) to detect this will never
be called. Propogating the exception out by default leaves the user with a
false sense of security, while a call to terminate() forces the user to
address the issue and pick the solution appropriate for the use case.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk