Messages in this thread | | | Date | Fri, 19 Jul 2013 09:22:14 -0700 | From | David Daney <> | Subject | Re: [RFC / musing] Scoped exception handling in Linux userspace? |
| |
On 07/18/2013 08:29 PM, Andy Lutomirski wrote: > On Thu, Jul 18, 2013 at 6:17 PM, David Daney <ddaney.cavm@gmail.com> wrote: >> On 07/18/2013 05:50 PM, Andy Lutomirski wrote: >>> >>> On Thu, Jul 18, 2013 at 5:40 PM, David Daney <ddaney.cavm@gmail.com> >>> 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
| |