Re: [basic-improvements] try/finally support for c/c++ - more tests

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Nov 07, 2002 at 08:12:05AM -0800, Mark Mitchell wrote:
> > Standards fixate existing practice, they don't establish it.
> 
> We've already got a standard that's relevant here.   In particular,
> we have the C++ programming language, which provides the functionality
> needed.  If you need that functionality, use that language, or another
> language (like Java, Ada, etc.) that provides that functionality.

As has been mentioned previously, compiling GNU libc as C++ is hard, since
it is a heavy user of -std=gnu99 features and extensions which are not in C++.

> Now, I'm not fully understanding how this is going to be used, which
> is perhaps coloring my thinking.  I'm getting the impression that this
> functionality is going to get buried in C headers that are going to
> get seen in *user* C code.  Is that true?

Yes, among other places.

> We're trying to implement one particular piece of functionality required
> by the POSIX threads interface; namely "pthread_cleanup_push" and friends.
> (I know that any feature might get used more widely, but this is the
> motivation, as I understand it.)  Furthermore, we're trying to make the
> POSIX threads cleanups play nice with exception-handling.  Or are we
> trying to use EH mechanisms to make things go faster?

Both. One goal is to make sure C++ destructors are run when cancelling a
thread, properly interleaved with C cleanups.
Of course the smaller overhead the mechanism has in the normal (ie. thread
is not being cancelled) case, the better.

> Anyhow, if I write:
> 
>   try { pthread_cleanup_push (...);
>         throw 3;
	  pthread_cleanup_pop (doit);
>	 }
>   catch (...) { }
> 
> and the system arranges to run the cleanup when the exception is thrown,
> the system is badly broken.

Implementation of pthread_cleanup_pop using __try/__finally would have to
do if ((doit) || __pthread_cancelling()) at the beginning of the __finally
block, so if you do pthread_cleanup_pop (0), the cleanup will not be run
when the exception is thrown, just when cancellation happens.
__pthread_cancelling may be just a simple TLS variable access.

Though if C has something like __try/__finally, then the programmer can as
well use it directly and not through the horrible pthread_cleanup_*
interface, while if pthread_cleanup_{push,pop} is implemented using
builtins which match exactly what pthread_cleanup_{push,pop}
is doing (as has been already suggested), then all the code is stuck
in using it.

	Jakub