public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org, gcc@gcc.gnu.org
Subject: Re: [RFC / musing] Scoped exception handling in Linux userspace?
Date: Thu, 18 Jul 2013 18:17:48 -0700	[thread overview]
Message-ID: <51E893BC.6070400@gmail.com> (raw)
In-Reply-To: <CALCETrXnVBPNGGTQQoXnpEmjXHxbhiWx+4RuMVQLRG5sfMpofA@mail.gmail.com>

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:
>>>
>>> Windows has a feature that I've wanted on Linux forever: stack-based
>>> (i.e. scoped) exception handling.  The upshot is that you can do,
>>> roughly, this (pseudocode):
>>>
>>> int callback(...)
>>> {
>>>     /* Called if code_that_may_fault faults.  May return "unwind to
>>> landing pad", "propagate the fault", or "fixup and retry" */
>>> }
>>>
>>> void my_function()
>>> {
>>>     __hideous_try_thing(callback) {
>>>       code_that_may_fault();
>>>     } blahblahblah {
>>>       landing_pad_code();
>>>     }
>>> }
>>
>>
>> How is this different than throwing exceptions from a signal handler?
>
> Two ways.  First, exceptions thrown from a signal handler can't be
> retries.

??

> 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.

David Daney


  reply	other threads:[~2013-07-19  1:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19  0:26 [RFC / musing] Scoped exception handling in Linux userspace? Andy Lutomirski
2013-07-19  0:40 ` David Daney
2013-07-19  0:50   ` Andy Lutomirski
2013-07-19  1:17     ` David Daney [this message]
2013-07-19  3:29       ` Andy Lutomirski
2013-07-19 16:22         ` David Daney
2013-07-19 19:07           ` Andy Lutomirski
2013-07-19  5:43 ` Tristan Gingold
2013-07-19 16:29 ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E893BC.6070400@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox