[linux-elitists] Re: Goto vs. named scopes

Jim Bray jb@as220.org
Wed Jan 15 09:00:58 PST 2003


  My delayed response to the interesting comments on the named scopes
idea. I appreciate your thoughts. I read the digest version, so these are
all in one message:

> From: Michael Bacarella <mbac@netgraft.com>

> That is one common use of goto in the linux kernel.
> 
> The other common use is in cleanup routines.
> 
> {
>     r = open_resource()
>     if (!r)
>         goto out;
>    
>     lock = allocate_lock()
>     if (!lock)
>         goto resource_out;
> 
>     if (r->thingy) {
>         lock->raise();
>         some_thingies();
>         if (can_do_thingy()) {
>             other_thingies();
>             if (exceptional_circumstance)
>                 goto release_lock_out;
>             more_thingies();
>             finish_thingies();
>         }
>         lock->lower();
>     }
> 
> release_lock_out:
>     lock->lower(); 
> lock_out:
>     free_lock(lock); 
> resource_out:
>     close_resource(r);
> out:
>     return foo;
> }
> 
> Not the most streamlined example but I think it illustrates
> my point.  Maybe I haven't thought about it enough, but could
> your extensions make that better?

  I'm not sure that they could. I had yet another harebrained idea at one
point when thinking about this particular problem, in which you are
gradually accumulating resources (locks, allocated objects, etc.), all of
which need to be released, in order, if one needs to abort. I think
Multics did something like this with the unwinder. My idea was to build a
list of structs of something like
struct unwind_item
{ 
  void *item;
  void *unwind_func(); //I'm rusty, but I mean pointer-to-function here...
} and then traverse and invoke in a generic unwinding function,
but that could be slow. The named-scopes approach to the above problem
would probably be to have a scope for each discrete level of undoing,
corresponding to each goto, and that would be a lot of tabs.

> From: Jay Sulzberger <jays@panix.com>

> call/cc gives you both.  The jump command is given a name and you may pass
> the jump command around as you may pass any procedure in (any) Lisp.  The
> place that is jumped to is just before/above the place call/cc is
> invoked/written, but the blue dot turns around and faces back/above before
> it lands.  "facing the other way" is most of the meaning of the mysterious
> "continuation".  The jump command takes one, or possibly more, inputs, and,
> when executed, jumps the blue dot to the place before/above the call/cc,
> and passes its input to whatever is waiting for the return value of the
> call to call/cc.

  This is interesting, but sounds like more of a Lisp thing. I'm not sure
it would fit into c and realtime coding well, but I could be wrong about
that.

> From: Nick 'Sharkey' Moore <sharkey@zoic.org>

> > The other common use is in cleanup routines.
> > [...] 
> > Not the most streamlined example but I think it illustrates
> > my point.  Maybe I haven't thought about it enough, but could
> > your extensions make that better?
> 
> Well, assuming that if 'break <label>' jumps to the end of
> the block labelled <label>, 'break' will jump to the end of the
> block ...
> 
> 
> int stoopid(int foo) 
> {
>     outer: {
>         r = open_resource();
>         if (!r) break;
> 
>         inner: {
>     	    if (something_didnt_work(r)) break;
> 	    stuff(foo);
> 	    if (something_else_didn't_work(r)) break;
> 	    stuff(foo);
> 	    if (resource_mysteriously_went_away_already(r)) break outer;
> 	    stuff(foo);
> 	    if (goddamn_it(r)) break;
> 	    stuff(foo);
>         }
>         close_resource(r);
>     }
>     return foo;
> }
> 
> 
> Something like that, anyway.  Most of the time the 'goto release_lock_out'
> construction is used it's just away of avoiding incredible levels of
> tabbing, though.

  The above is exactly the idea. I think the named scopes approach makes
it look better, but the tabs could get out of hand. The unwinding problem
that Michael brought up is challenging, and something in addition to named
scopes is called for there, even if they can help with it.

Jim



More information about the linux-elitists mailing list