Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-08-06 12:58:08

--- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Hillel Y. Sims" <hys420_at_y...> wrote:
> > > Pthreads has a limited, well-defined set of cancellation points
> > > ordinary conditions), thus is it 100% possible and not that
difficult to
> > > write completely non-throwing code even with thread-cancellation
> > > implemented in terms of exceptions in a pthreads-based
environment, by
> > > simply avoiding any functions that could potentially evoke a
> > > thread-cancellation exception (since it's not valid to use
catch (...) {}
> > > to swallow these exceptions, we would have to completely avoid
> > > any of these calls inside true non-throwing code, but that
doesn't really
> > > seem like a horrible restriction).
> >
> > This means you can never make a call to a routine defined as a
> > cancelation point within a destructor. Much too restrictive for
> It seems that to program in this system you have no choice but to
> live with this restriction. Depending on the list of functions it
> might not be too bad.
> Hillel -- does the list include close() and free() and such?

It includes mutex locks, condition waits, thread joins, all of which
would be very likely candidates to be called within an object
destructor. In fact, requiring that you not call these in
destructors would be nearly impossible.

> > > (I don't really do Windows, so I don't know if it has similar
> > > cancellation semantics..)
> >
> > Windows has no cancellation semantics, only asynchronous
> > which is 1000 times worse.
> Does this mean that on Windows there is no way to emulate pthread
> cancellation semantics?

No, it can be emulated, but there's zero support from the OS.
pthreads-win32 emulates cancellation using exceptions (and so suffers
from the problems I've listed). There's likely other ways to emulate
this as well, just as people have emulated exceptions, but it would
be non-portable and likely have holes.

POSIX specifically defined cancellation to behave as if an exception
was thrown across thread boundaries (though it requires "polling"
within cancellation points), and on many systems OS exceptions are
actually used. On a lot of these systems the OS exception is
promotable to a C++ exception so there are already platforms in which
the suggestion of using a C++ exception is already the case.
Further, Java uses this concept making it sound like a natural
solution for C++ as well, but C++ isn't Java.

These are the problems I see with Boost.Threads doing this, however:

* Portability. Translating a pthreads cancellation which is
implemented in terms of a signal into a thrown exception can not be
done portably. We'll have to have system specific code for each

* Can not call any methods that represent cancellation points
(remember, if a function foo calls a function bar that calls a
function defined to be a cancellation point, then foo is also a
cancellation point) in a method defined with empty throw
specifications. Some argue that this is simply how it should be
since obviously the method can throw if it calls a cancellation
point. However, with other exception types you can catch the
exception and not propogate it up past the call, while with a
cancellation exception you have to rethrow the exception.

* Can not call any methods that represent cancellation points from a
destructor. It's a very frequent need to do just that, but doing so
can result in an exception being thrown out of the destructor which
disallows the object from inclusion in many container types and when
created on the stack can result in application termination if the
stack is being unwound because of another thrown exception. The
complexit in this case is too great to be safely usable.

The language can address these issues, but a library written to the
current standard can not.

Bill Kempf

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