[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_c_catch question
Re: scm_c_catch question
Sat, 16 Aug 2014 15:24:54 +0200
On 2014-08-16 00:13, Ian Grant wrote:
Hello Guile types,
I have been experimenting with using libguile from within another
byte-code interpreter: Moscow ML. I have a version of Moscow ML with
an GNU lightning interface in which I JIT compile primitives to give
access to libguile functions from Standard ML.
Moscow ML uses an old version of the CAML light runtime which is a
byte-code interpreter implemented in C. The CAML runtime provides
exceptions implemented using a longjmp buffer.
The Moscow ML top-level REPL is implemented as a byte-code compiled ML
function which is invoked by main(). What I would like to do would be
to catch any unhandled Guile exceptions and re-throw them as ML
exceptions so that the toplevel isn't exit'ed by an un-handled scheme
exception. To this end I call the CAML main from the scm_boot_guile
callback, under a scm_c_catch. This code is in the guilert.c file
 The only CAML'ism here is the call to failwith("message"). This
does a longjump 'into the CAML exception bucket'
The problem is that after the first successful catch by the pre-unwind
handler, the next Guile exception is handled by the main_handler. This
is not what I expected. The manual seems to say that it is only after
the main_handler is invoked, that the catch is cancelled. Is this not
the right understanding?
It was a while ago, but it was me who first implemented that pre-unwind
handler. So maybe I can help here.
No, I don't think that is the right understanding. The manual (at least
for 2.0.11) says:
A PRE-UNWIND-HANDLER can exit either normally or non-locally. If
it exits normally, Guile unwinds the stack and dynamic context and
then calls the normal (third argument) handler. If it exits
non-locally, that exit determines the continuation.
In either case, I believe the intention is for any exception to
terminate the catch. In the case where the pre-unwind handler exits
normally, the catch is terminated after the main handler has been
called. In the case where the pre-unwind handler exits non-locally, I
think it's assumed that the new context is somewhere outside of the
catch, and hence that the catch is no longer in effect.
In either case, therefore, handling any subsequent exception should
require establishing a new catch.
In your code, the pre-unwind handler calls failwith() and doesn't expect
it to return - so where does it jump to?