Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 16:05:05

----- Original Message -----

This part made no sense to me:

<<From: "terekhov" <terekhov_at_[hidden]>
Anyway, that was a WRONG solution! catch(...)/
cancellation/exit is a moot point, I think.
I just rushed in without too much thinking and
should not have done it in the first place because
a) auto_rethrow_exception() just breaks catch(...)
without throw; semantics and b) thread cancel/exit
should NOT be caught without throw; (or
program termination) at all!! Look, you could
always control cancellation (using cancel state
and type) and thread exit exception could carry
not so smart objects (to return to joiner(s))
which could result in resource leaks catching
it without throw; or program termination. Such
code is simply broken! It is just a breach of
contract, I think.>>

But this did:

<<"There are several important blocking routines
 that are specifically not made cancelation points:
 — pthread_mutex_lock()
 If pthread_mutex_lock( ) were a cancelation point,
 every routine that called it would also become a
 cancelation point (that is, any routine that touched
 shared state would automatically become a cancelation
 point). For example, malloc(), free( ), and rand()
 would become cancelation points under this scheme. >>

I think free() in particular would be a particularly bad one. It's basically
the same issue as "what operations should be allowed to throw?" However, I
think that a C++ library can afford to be much more liberal with
cancellation points than a C library can in general, because C++ programmers
are (at least starting to become) aware of the presence of exceptions. I
guess I would support making mutex locking a cancellation point as long as
the important operations which used it(e.g. free(), operator delete(),
rand()) disabled cancellation.

-Dave