Re: [RFC / musing] Scoped exception handling in Linux userspace?

[David Daney]

On 07/18/2013 08:29 PM, Andy Lutomirski wrote:
> On Thu, Jul 18, 2013 at 6:17 PM, David Daney <ddaney.cavm@xxxxxxxxx> wrote:
> > On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
> > > On Thu, Jul 18, 2013 at 5:40 PM, David Daney <ddaney.cavm@xxxxxxxxx>
> > > wrote:
> > > > On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
> > > >
> > > >
> > > > How is this different than throwing exceptions from a signal handler?
> > >
> > >
> > > Two ways.  First, exceptions thrown from a signal handler can't be
> > > retries.
> >
> >
> > ??
>
> s/retries/retried, by which I mean that you can't do things like
> implementing virtual memory in userspace by catching SIGSEGV, calling
> mmap, and resuming.
>
> > > Second, and more importantly, installing a signal handler in
> > > a library is a terrible idea.
> >
> >
> > The signal handler would be installed by main() before calling into the
> > library.  You have to have a small amount of boiler plate code to set it up,
> > but the libraries wouldn't have to be modified if they were already
> > exception safe.
> >
> > FWIW the libgcj java runtime environment uses this strategy for handling
> > NullPointerExceptions and DivideByZeroError(sp?).  Since all that code for
> > the most part follows the standard C++ ABIs, it is an example of this
> > technique that has been deployed in many environments.
>
> Other way around: a *library* that wants to use exception handling
> can't do so safely without the cooperation, or at least understanding,
> of the main program and every other library that wants to do something
> similar.  Suppose my library installs a SIGFPE handler and throws
> my_sigfpe_exception and your library installs a SIGFPE handler and
> throws your_sigfpe_exception.  The result: one wins and the other
> crashes due to an unhandled exception.
>
> In my particular usecase, I have code (known to the main program) that
> catches all kinds of fatal signals to log nice error messages before
> dying.  That means that I can't use a library that handles signals for
> any other purpose.  Right now I want to have a small snippet of code
> handle SIGBUS, but now I need to coordinate it with everything else.
>
> If this stuff were unified, then everything would just work.

That's right.  But I think the Linux kernel already supplies all the 
needed functionality to do this.  It is really a matter of choosing a 
userspace implementation and standardizing your entire system around it. 
 In the realm of GNU/GLibc/Linux, it is really more of social/political 
exercise rather than a technical problem.

David Daney

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/