Boost logo

Boost :

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

> --- 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at