Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-22 13:22:41

--- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> williamkempf_at_h... wrote:
> > > If you don't, people will have to roll their own.
> >
> > Which is a safer approach.
> > Seriously. This may sound backwards,
> It doesn't sound backwards. You're probably right.
> The arguments you present suggest that there would be no
> consensus on the ISO WG if cancellation were part of the
> library. It is OK (IMHO) to have a restricted set of thread
> handling facilities that will make it easier to solve
> a reasonable class of problems, while still requiring
> more sophisticated systems to roll their own.
> > Some of the issues:
> >
> > 1) Cancellation usually doesn't address lifetime issues
> > or appropriately. For instance, pthread cancellation and Win
> > cancellation when used in the C++ language fails to properly call
> > destructors.
> This is an issue which needs to be addressed by the
> Standardisation committee. But first, the abstract machine
> needs to be extended to support the notion of threads. :-)

Which is something that can be done when the C++ standards committee
chooses to adopt a threads concept, and we do hope that the Boost
effort is considered at that time. However, the Boost effort can't
address this, because we can't change the abstract machine (at least
not easily or portably). That's why I've said that cancellation
*may* be considered. It is a feature that most people are going to
want... and that despite the fact that historical evidence shows it
to be dangerous even when it's a part of the language. But because
of the dangers and the complexity, I'm not going to make it a feature
of Boost.Threads any time in the near future.

> This is also necessary before any threads library
> (even a simple one) can be accepted as a part of the Standard
> Indeed, if the only consequence of proposing a boost::threads
> is that the abstract machine is modified to support thread concepts,
> the library will have been very useful.
> I'll add:
> Posix cancellation points are deficient, there are a couple
> of socket calls which block, but which are not cancellation points.
> > A language solution instead of a library solution can eliminate
> > but not all of these problems. Again, look at Java for proof of
> [Best not to start me off on a rant :-]

Hey, I dislike Java as much as the next guy, but Java has shown many
of the dangers in a poor thread design that every language/library
should pay attention to. Cancellation is a big one. I'm not sure
that a safe form of cancellation can be done, despite how easy it is
to add cancellation explicitly to thread routines.
> > Explicit user cancellation coded with condition variables are
> > to implement, and are fully safe, however.
> Provided all blocking system calls are wrapped with checks
> on the condition variables. So you must use the wrapper code
> exclusively (can't use C calls). Probably, this is acceptable.

You're bringing up another issue here that's pertinent to only a
portion of designs that need cancellation. For realtime systems that
need immediate cancellation (i.e. they can't wait until after a
return from a blocking routine) a wrapper is going to be problematic
and a library supplied cancellation mechanism is likely going to be a
necessity. However, experience shows this need to be in the
minority, so weighing the pros and cons leaves me still wanting to
ignore cancellation.

Bill Kempf

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