Re: [c++-pthreads] Re: thread-safety definition

[Ted Baker <baker@xxxxxxxxxx>]

> Except for the fact that we have normally-non-throwing functions that
> have started to throw, I don't think anyone's disagreeing with you.

This still perplexes me.  How does a "normally-non-throwing function"
"start to throw"?

The examples I recall seeing here are of C/C++ library
functions that make system calls via C library routines that are
cancellation points.

1) It is normal for these C library routines to be cancellation
points, in any POSIX/Unix/DCE multithreaded program.  Cancellation
is semantically equivalent to an exception, so these are not
normally-non-throwing functions.

2) It may be that the existing implementations of some other C++
library functions call such potentially-throwing
C library functions, and these C++ library functions are not
documented as potentially throwing exceptions.
These functions do start to throw exceptions if you move from
a multithreading environment that does not support cancellation
to one that does.

If that is the only problem, it seems you have a few possible
alternative solutions:

A) Modify the C++ library function implementations so that
they call "safe" versions of the C library functions, that
are not cancellation points.  This could be done by either
changing the sources of the C++ libraries to call the safe
versions by name, or by using macro or linker-level renaming
to do the substitution.

B) Change the documentations (maybe standards) for the affected
C++ library functions, to specify that they may throw thread
cancellation when cancellation is enabled.

C) Disable cancellation by default in all C++ threads, and
warn users that enabling cancellation may cause some functions,
not documented as throwing, to throw cancellation.

Beyond that, I get the impression this group is asking for
something that is impossible because it is self-contradictory,
i.e., for a way to (1) allow cancellation, (2) ensure (1)
cancellation cannot be ignored for long or lost, (3) not allow
throwing of cancellation from certain library calls, (4) not make
any change to existing code for those library functions (which
were written without cancellation in mind).

--Ted