From: Scott McCaskill (scott_at_[hidden])
Date: 2001-08-03 09:44:36
----- Original Message -----
From: <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 03, 2001 9:32 AM
Subject: boost.threads [was RE: [boost] Re: sockets /network programming
Requirements]
> --- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > > > Right now it checks (polls) periodically to see if any have
> ended.
> > > I'm
> > > > considering what the implications would be if I changed it to
> wait
> > > (block)
> > > > until any thread ended.
> > >
> > > Just curious, but what does it do if the poll indicates a thread
> has
> > > died?
> > >
> >
> > Currently it just logs an error, but for some threads we may want
> to start
> > them again. The design is still evolving, as you may have
> guessed ;)
>
> Well, keep me informed of areas you find in which Boost.Threads seems
> to be lacking functionality you need.
>
> As for this particular discussion, in the near future (before
> submission which is coming very quickly *yikes*), the tss class will
> support cleanup handlers even on Win32 and could be used to signal
> the condition. That said, however, I'd strongly recommend you avoid
> thread exits in your code any way. I'm not sure how POSIX threads
> work in this regard (though I'd expect the same behavior), but a call
> to ExitThread in Win32 does not unwind the stack properly in C++. In
> other words, destructors for objects on the stack are not called. In
> a C++ program this can mean a lot of resource leaks occur. Even SEH
> __finally blocks aren't run. It would simply be safer to restructure
> your code to not have multiple exit points. This is the reason
> Boost.Threads doesn't have a thread:exit() or define cancellation
> points.
>
Oh yes, I totally agree, and will eliminate such calls if I find them (I'm
not working alone). Just trying to "program in the future tense", as Scott
Meyers once said.