Re: [boost] Re: Digest Number 754

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-06 11:13:33

From: <williamkempf_at_[hidden]>
> --- 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?

 
> > (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?