Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15678

Re: Exception propagation in C

Cross-posted to 2 groups.

Show all headers | View raw

On 2012-01-09, James Harris <james.harris.1@googlemail.com> wrote:
> On Jan 9, 5:41 am, Scott Wood <sc...@buserror.net> wrote:
>
> ...
>
>> >> 2) Accessing that machine word by polling, as you propose can't be done
>> >>     in one instruction since you need the thread ID to be able to access
>> >>     the thread local storage.
>>
>> > No, for option 3 the word is changed on a thread switch. I have
>> > explained this too.
>>
>> And it's been explained to you that "changed on a thread switch" doesn't
>> work unless this is CPU-local storage by some other mechanism.
>
> If you mean your comment four days ago, I did reply. I said that I
> didn't understand what you meant but you said no more. Not what I
> would call 'explained' to me! :-(

Hmm, sorry about that -- I thought I replied, but I can't find it now.  I
may have had the reply open when my computer crashed.  Something in the
Linux kernel branched right into the middle of an instruction (probably
corrupted memory, maybe rotting hardware). :-(

>> More than one thread can be running at the same time -- no switching, no
>> opportunity to swap the magic variable.
>
> I've been puzzling over this. The only thing I can think that might
> cause a problem is multiple threads running in the same address space
> on different CPUs. Is that what you mean?

Yes, that's what I mean.  Swapping on thread switch is only viable for
per-CPU storage, and if the whole point is to have a fixed virtual address,
that means you need a separate MMU context -- which is doable, but at the
point that I'd question whether it's really worthwhile.

A summary of what I recall of the rest of the reply:

> 2. The scheme proposed will work between languages. I don't intend the
> use of many languages but as an example, a Pascal routine could call
> an assembly routine which could call a C routine which could call
> another assembly routine and all of them could follow the same, very
> fast, exception propagation protocol. (More accurately, the point is
> that each would very quickly skip non-exceptions while still handling
> exceptions.)

It won't skip them as quickly as native compiler exception handling -- but
yes, you'd need some glue code around language transitions unless all the
languages involved implement the same exception mechanism (asm could be made
to, others maybe with compiler extensions?).  How often are potentially
cross-language calls made, compared to component-internal calls?

If you need something that works in a wide variety of languages without glue
or other hassle, it sounds like simple return values are the way to go.  You
can combine errors and successful return values as long as they have
disjoint ranges (often negative for errors, non-negative for success), so
for many functions you may not need an extra pointer parameter.  Perhaps you
could stick a full error report struct in true TLS (you wouldn't need to
access it in the no-error case, so it's not as speed-sensitive), but be
careful that such structs can't leak.

>   if (ex = a()) {if (handler(&ex)) return ex;)
>   if (ex = b()) {if (handler(&ex)) return ex;} 

What would go in handler()?  I'd think you'd usually want to make the
decision locally about whether/how to handle or propagate and clean up from
the error.

> 3. It doesn't allow a sticky exception state such as
> 
> a();
> b();
> if (thread_excep) /* An exception occurred in a() or b() */ 

I've only occasionally felt the need to do this -- often I'd want to clean
up differently, or I wouldn't want to call b() if a() failed.

> If I wanted to add a sticky state I suppose I could write
> 
>   if (ex |= b()) ...
> 
> but that puts the OR instruction (and possibly a memory update) into
> the main non-exception processing path so would be slower in the
> normal processing case. 

Doing a load from memory followed by a compare and conditional branch will
also slow down the normal processing case.  A few ORs is well worth
eliminating a bunch of loads.

> I'm not ruling it out completely. It does do away with the goto. 

Don't fear the goto -- it's one of the nicer ways of doing error cleanup in
C that I've seen.  The Linux kernel uses it extensively.

-Scott

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-29 09:52 -0800
  Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-29 19:40 +0100
    Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 14:03 -0600
  Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 13:07 -0600
    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 13:38 -0800
      Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-30 20:24 -0600
        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 02:19 -0800
          Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-03 14:04 -0600
            Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-04 04:26 -0800
              Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:05 -0600
                Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-06 23:54 +0100
                Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-06 22:24 -0600
                Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-07 09:15 +0100
                Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-08 23:45 -0600
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 12:52 -0800
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 14:20 -0800
                Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:19 +0100
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 21:12 -0800
                Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 23:41 -0600
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:00 -0800
                Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-10 00:42 -0600
                Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-11 07:40 +0000
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-11 12:59 -0800
                Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 00:05 -0600
                Re: Exception propagation in C Ian Collins <ian-news@hotmail.com> - 2012-01-09 20:40 +1300
                Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 04:53 -0600
                Re: Exception propagation in C 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 05:49 -0800
                Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 17:29 -0600
                Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:37 +0100
                Re: Exception propagation in C Nomen Nescio <nobody@dizum.com> - 2012-01-09 11:36 +0100
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:08 -0800
          Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-05 01:25 -0600
            Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-05 09:18 -0800
      Re: Exception propagation in C "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2011-12-30 21:20 -0800
        Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 06:19 -0500
        Re: Exception propagation in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 10:32 -0800
      Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 05:53 -0500
        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-01 16:30 -0800
          Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 01:50 -0500
            Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-02 02:03 -0600
              Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 15:59 -0500
                Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:12 -0800
                Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-04 23:53 -0600
                Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-05 06:45 -0500
            Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:16 -0800
              Re: Exception propagation in C Keith Thompson <kst-u@mib.org> - 2012-01-03 11:50 -0800
      Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2011-12-31 13:40 +0100
        Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-31 10:40 -0600
          Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-02 16:49 +0100
            Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-02 13:02 -0600
              Re: Exception propagation in C Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-02 19:53 +0000
                Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 13:10 -0800
              Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 12:58 -0800
              Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-04 18:01 +0100
                Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:38 -0600
                Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-06 21:40 -0500
  Re: Exception propagation in C Kaz Kylheku <kaz@kylheku.com> - 2011-12-29 21:02 +0000
    Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-30 10:38 +0100
    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:38 -0800
  Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-29 18:37 -0500
  Re: Exception propagation in C "BartC" <bc@freeuk.com> - 2011-12-30 01:07 +0000
    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:07 -0800
  Re: Exception propagation in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-30 17:53 -0500
    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:56 -0800
  Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-02 09:49 +0000
    Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-02 10:51 +0000
      Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 16:01 -0500
        Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 11:14 +0000
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:59 -0800
        Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 12:09 +0000
  Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-03 21:25 +0000
    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-02-15 14:24 -0800
      Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-02-17 22:38 +0000

csiph-web