This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: unwind question


Dietmar Maurer <dietmar@ximian.com> writes:

> On Wed, 2002-11-20 at 18:42, Owen Taylor wrote:
> Dietmar Maurer <dietmar@ximian.com> writes:
> 
> > On Wed, 2002-11-20 at 17:42, Martin v. Löwis wrote:

[..]

> > > > 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...
> 
> Good point. Its that strange ThreadAbort() feature of .Net which
> triggers those things. Under .Net you can Abort an Asynchronous
> ThreadAbort(), so that the thread continues.

The last paragraph in:

  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmanagedunmanagedthreadinginmicrosoftwindows.asp

seems to indicate that ThreadAbort() has similar limitations
in the Microsoft CLR to what you'll need to do... you 
simply can't throw an exception at a random point in code
that isn't expecting it.

> > 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.
> 
> So it really true that all libc functions either have unwind info, or
> they cant raise synchronous exceptions? 

I see no reason to doubt that.. :-) Of course very few libc
functions actually have callbacks.

Regards,
                                        Owen


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