Re: Help: Unwinding the C++ stack...throw, longjmp & threads

[Ulrich Drepper <drepper@cygnus.com>]

"George T. Talbot" <george@moberg.com> writes:

> What would be an acceptable size increase?  Did the people who
> complained say what would be acceptable or did they just complain?
> ;^)

The latter, of course.

> What methods do you guys use now to determine what is and what isn't
> an acceptable performance hit when, say, you're experimenting with
> different compiler optimization flags?

I don't have to run performance data.  If a feature effects everybody
and is hardly used by anybody it's not worth it.  If the effect is
minimal (i.e., a handful of additional assembler instruction or a few
bytes of data where needed) this is ok.  But simply enabling
fexceptions is not.

> I'm trying to get an idea of what is and what isn't acceptable.  I
> have no problem doing the hard work of implementing a fix to
> pthread_cancel() under Linux, and I have no problem doing the hard
> work of measurement, but I need some objective criteria for doing
> the measurement so I don't walk down a dead-end path.

I like the idea of using the exception mechanism to handle cancelation
even in C.  So what has to be done is:

- implement a usable interface to the exception handling in gcc (not g++).
  It must be possible to define macros named pthread_cleanup_push() and
  pthread_cleanup_pop() and use them like this:

	pthread_cleanup_push (func, arg);

	... do lots of work ...

	if (some condition)
	  {
	    ... do what is necessary to leave the frame ...
	    return;
	  }

	... more work ...

	pthread_cleanup_pop (doit);

  This roughly has to be converted to something like:

	try
	  {
	    ... do lots of work ...

	    if (some condition)
	      return;

	    ... more work ...

	    if (doit)
	      throw (_posix_cancelation_exception_object);
	      // Alternatively do the call directly:
	      // func (arg);
	  };
	catch (_POSIX_CANCELATION_EXCEPTION &exc)
	  {
	    func (arg);
	  };

  I.e.:

  + leaving the frame must somehow be handled

  + the function to be called (and it's always only one function) is
    named in the push call at the beginning (contrary to the C++
    syntax)

  + one must be able to throw an exception (in the example above as
    well as in the cancelation call of the library)


- functions which must be compiled with exception handling enabled must
  be identified.  These include:

  + functions which are cancelation points:

  + functions which use callbacks and those directly or indirectly using
    functions which use callbacks


If things are implemented this way I could argue that the new scheme
should be used since it is probably faster than the current implementation.


If you can come up with a scheme which works for the case above (I
hope I covered all cases) I'd like to learn about it.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------