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

[David Daney <ddaney.cavm@gmail.com>]

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