Re: Digest Number 754

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 
(under
> > > 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 
invoking
> > > 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 
me.
> 
> 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 
thread
> > > cancellation semantics..)
> > 
> > Windows has no cancellation semantics, only asynchronous 
termination, 
> > 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 
platform.

* 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