This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: catch(...) and forced unwind


On Mon, Dec 15, 2003 at 04:21:29PM -0800, Ulrich Drepper wrote:
> No.  A canceled thread cannot continue.  Period.  There is no room for
> discussion.

Ulrich, what you are describing is SIGKILL.  If _any_ cleanup code
is to run, the thread really is continuing, at least for a while.  
That means that the details of what happens as the code runs matter.  
We need for those details to be consistent with language semantics 
that existing code (at least some existing code, as we'll see) 
depends upon.  

Main programs can be assumed to know they're running under special
circumstances.  They can be required to have set up any environment
details that matter, and to be coded peculiarly to accommodate 
oddities in runtime behavior.  For a library, it's different.  A 
third-party library cannot set environment details.  In any case, 
it doesn't know enough about the threading regime it's running in
to set them properly.

If threading makes language semantics too different, then threaded
programs that might include cancellation can't use libraries.  The
universe of programs that can practically be written without using
libraries is very small indeed.

Our task is to discover an accommodation so that libraries can 
do the Right Thing without knowing whether they are in a thread
that has been, or might be, cancelled.  We can demand almost 
anything of the main program to make that possible.  This is 
familiar territory; thread-safety and exception-safety discipline
are well-known to competent library coders.  

As an example of an accommodation, most C++ libraries don't call C 
code directly.  However, they often call back into user-supplied code 
that itself might call C functions, which might be cancellation points.
It might be OK for a cancellation-safe library not to be allowed to
call external C code directly, and require instead that the main
program provide wrappers for any code that might hit a cancellation
point.

The alternative to discovering an accommodation for libraries is to
announce that you have made a thread cancellation apparatus that is 
incompatible with C++, or with C++ libraries.  If that's where we end 
up, that's also where we started.  If thread cancellation is useful 
at all, we need to figure out under what limitations it can safely 
be used, and design the semantics we control to ensure that those 
limitations are minimal, or at least reasonable.

Nathan Myers
ncm@cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]