Re: unwind question

[Owen Taylor <otaylor at redhat dot com>]

Dietmar Maurer <dietmar@ximian.com> writes:

> On Wed, 2002-11-20 at 17:42, Martin v. Löwis wrote:
> > > But I soon detected that there is no unwinding information available
> > for
> > > functions contained inside libc. So if an exception occurs inside
> > those
> > > function it is impossible to unwind the stack, even when they are
> > called
> > > from function which has unwinding information?
> > >
> > > Is this true, or is there a way to solve that somehow?
> > 
> > Yes, and no. Those functions that can cause exceptions
> > (i.e. those that call back user code) are compiled with -fexception
> > (qsort being the most prominent example). You should not need
> > to worry about the functions that have no unwind information since
> > you will never see them on your stack.
> 
> Thats wrong. Any asynchrounous signal can interrupt any code, so this is
> a real problem for us.

It seems very unlikely to me that it will ever be safe to
throw exceptions from signal handlers in random parts of 
libc code...

Even assuming that:

 a) You had compiler support for try blocks in C [which is coming]
 b) The setup of try blocks and stack frames is safe against 
    interruption [which I doubt]

The extra code complexity and performance loss to add protection
everywhere would be prohibitive. Side effects and memory allocation 
in libc aren't as pervasive as as in many libraries, but they
certainly are still there.

Mono really needs to wait until the native code returns to 
run your C# signal handlers for Unix signals.

Regards,
                                        Owen