Re: boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

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.