Re: Exception-safety for C++ code integrated with Guile.

[Andy Wingo]

Hi Taahir,

On Mon 23 Feb 2015 22:59, Taahir Ahmed <address@hidden> writes:

> Over the past few days, I've been working on reducing the amount of
> defensive coding that is required when writing Guile extensions using
> C++.
>
> My primary goal is to ensure that destructors of automatic variables
> are called if any Guile non-local control flow passes through a C++
> stack frame.

I was thinking about this recently too, in the context of GDB's upcoming
switch to C++, though I didn't get very far in the thinking.

>   1) To check that I'm not duplicating any other ongoing work,

Not that I know of.  Doesn't matter anyway, a good solution is always
acceptable :)

>   2) To float two different implementation strategies and see which
>      one is the best choice going forward, and
>
>   3) To get clarification on some issues that I've encountered with a
>      prototype implementation.

Cool.

> The two major strategies I considered are:
>
>   1) Replace all uses of set/longjmp in the Guile source with C++
>      exceptions.  This approach is simple in some ways, and
>      complicated in others.  I would hesitate to pursue this unless
>      Guile has some sort of longer-term plan to move towards C++.

I am not C++-averse but a hypothetical move towards C++ in a Guile
context doesn't necessarily mean moving towards use of exceptions.
Scheme has fairly complicated control flow and embracing C++ exceptions
doesn't necessarily solve things.  For example an exception propagating
over natively-compiled Scheme code would have to run dynwinds.  Calling
out to C++ would have to set up some sort of try/catch.  Is that the
right design?  I don't know.

(I do think that the C-stack-saving aspect of Guile's continuations is a
silly thing, given that delimited continuations are more expressive, we
can have escape-only continuations either way, and our VM and future
native compilation pipeline means that we don't have so much rewinding
of C stack frames, and in any case rewinding is unexpected and untested
by most Guile core code, not to mention user code.)

>   2) Replace all uses of set/longjmp with replacements (call them
>      eh_setjmp and eh_longjmp) that are based on libunwind [1].

No opinion other than a vague aversion to dependencies.

> However, I've run into an issue --- many of Guile's uses of setjmp
> don't conform to the C standard.  In particular, after experiencing a
> non-local return from setjmp, you're not allowed to access any
> non-volatile local variables, but Guile does (see the local variable
> mx in eval()).

You are allowed to access variables that could never be assigned after
the setjmp, AFAIK?  Anyway how is mx accessed before being re-set after
a prompt longjmp?

Cheers, and thanks for looking at this,

Andy
-- 
http://wingolog.org/