This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: feature?


Nicolas Neuss <Nicolas.Neuss@IWR.Uni-Heidelberg.De> writes:

> Lynn Winebarger <owinebar@free-expression.org> writes:
> 
> > Would anyone else be interested in having guile return a continuation
> > if it recieves an interrupt signal?  I've been doing some stuff with it
> > that makes my system go swap-crazy, and I'd like to be able to stop it in
> > the middle of the computation, look at what it's doing, and then restart
> > it from there.

It would be dangerous to have this as a default behaviour since some
processes can build up large stacks.

However, it is certainly possible to implement, even at the Scheme
level, actually.

Install a "lazy-catch" handler which saves the continuation in some
variable and re-throws the signal.  Then restart using this
continuation.  All of this is possible to put into a Scheme procedure
so that you could do:

  (call-restartably thunk)

and to continue:

  (restart)

> Three weeks ago I asked about such a feature.  So I would be
> interested.  On the other hand, it may be non-trivial.  Here, the
> answer by Telford Tendys:
>
> #  I doubt that it is possible, a longjmp() call is used for errors and
> #  it isn't usually reversable. The documentation for setjmp() and
> #  longjmp() doesn't make it clear what happens when you try pinging
> #  back and forth between two of them but my guess is that it fails.

It is not clear to me what he means by this.  call/cc is implemented
using longjmp.  What you can't do by *only* using longjmp is jumping
further down the stack---you have to initialize that memory first, and
this is what the stack copying call/cc does.

> #  Another alternative is to replace the normal error handler with one that
> #  piles MORE on the stack rather than the standard one which drops back.
> #  Some LISP systems and some other schemes do this, I'm sure it wouldn't be
> #  hard to write one like this for guile.

Not necessary.  This is how Guile handles errors.  There are two
layers of handlers: one which does things before popping the stack,
and one which does things after.

> #  What basically happens is that a
> #  new REPL is started on top of the existing calculations so that you are
> #  still at the same place inside the calculations. On a good day you can
> #  debug back down the stack that you are sitting on, change a few variables
> #  and set it going again.

What I've said above is that it should be possible to restart after
signals.  Restarting after some types of errors is fairly easy to
implement in Guile, but requires changes to error handling.  There are
no plans to do this now.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]