[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scm_c_catch question

From: Neil Jerram
Subject: Re: scm_c_catch question
Date: Wed, 20 Aug 2014 20:02:33 +0200
User-agent: Roundcube Webmail/0.9.5

On 2014-08-18 03:14, Ian Grant wrote:
Hi Neil,

Sorry, I am replying to my message because I'm not on guile-devel, it
seems. I'll join later.

Thanks for clarifying that. The misleading statement in the manual is
just above the paragraph you quote: on
[2] it says

    Handler is invoked outside the scope of its own catch. If
    again throws to the same key, a new handler from further up the
    call chain is invoked.

It doesn't mention pre_unwind_handler, which implies that the
statement does _not_ apply to pre_unwind_handler.

Yes, I believe it is correct that those statements do not apply to the pre-unwind handler.

So this should be

But it would be more useful if there were a way to allow a throw to be
aborted as I was expecting. How hard would that be to implement? If
you think the semantics are in fact different, it could be given a new
name, scm_c_catch_and_rethrow or something. What I want is something
like BSD signals semantics, where the handler is not reset when the
signal occurs.

You ask "In your code, the pre-unwind handler calls failwith() and
doesn't expect it to return - so where does it jump to?"

I thought I had explained that, sorry. The call to failwith() does a C
longjmp back into the CAML bytecode interpreter (i.e. back down below
the call stack into caml_main). This is not a non-local exit, as far
as Guile is concerned, because it is just a 'naked' C longjmp. So in
that sense, the second time Guile throws an exception it is being
thrown from within pre_unwind_handler.

OK, I think I see now. From Guile's point of view, the dynamic context of the 'catch' remains in effect - as you want - but with a flag to say that the pre-unwind handler is already running (actually implemented by the %running-exception-handlers fluid in boot-9.scm). That explains why the _next_ exception causes the catch's main handler to be called, instead of the pre-unwind handler again.

Is there a way to implement what I want with fluids?

I don't think so, no. Basically what you need is to make some call, from the pre-unwind handler code, just before calling failwith(), that says "this pre-unwind handler should now be reactivated" and is implemented by removing itself from %running-exception-handlers. But %running-exception-handlers is hidden inside a lexical environment, so that isn't possible without hacking the boot-9 code.

You could try hacking the boot-9 code, though, to see if that idea works, and then propose a patch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]