Re: embedding mzscheme into a C++ application

[Matthew Flatt <mflatt@cs.utah.edu>]

Sorry for the delay. (Sometimes mail gets buried.)

Quoting Chris Uzdavinis:
> There is one concern that I have
> regarding many embedded script languages, and that is the use of
> longjmp.  In a C++ application, if a longjmp jumps over any object
> destructor, your program is undefined.
> [...]
> 
>  1) scheme code ---> 2) c++ code ---> 3) scheme code
> 
> 
> Suppose scheme code in section 3 wants to long jmp to a handler in
> scheme code (1). 

One possibility is to diallow the jump.

When you use the non-underscored versions of the MzScheme entry points
(e.g., scheme_apply() instead of _scheme_apply()), full-continuation
jumps in either direction are already disabled. That provides minimal
sanity from the point of view of C/C++ code, which expects a single
return from the Scheme code.

To block the remaining jumps (i.e., escape continuation jumps), you can
catch the longjump and ignore it. [This turns out not to be a special
power of C code. Jumps can be blocked in Scheme, too, using
`dynamic-wind'.]

MrEd (implemented in C++) used to ignore escapes that way. But we've
eliminated the need for any clean-up actions --- it helps to depend on
GC --- so MrEd allows the jump.

Now, I suppose you want to allow escaping jumps (e.g., for raising
exceptions) and you really need destructor-based clean-up...

> Basically, what needs to be done in every C++ routine that interacts
> with scheme (especially if it's reentrant from scheme, as in 1->2
> above), it needs to catch any long jumps, clean up all local objects,
> and then re-jump to wherever the original long jump was headed.
> 
> But I am not sure how to do that cleanly, since mzscheme encapsulates
> the setjmp/longjmp routines, and I haven't bothered yet to look at
> what they do.

I'm not up-to-date on C++: has the exception mechanism become widely
implemented?

If so, couldn't you catch the longjmp at the C++->Scheme boundary,
raise a C++ exception, catch the exception at the Scheme->C++ entry
point, and longjmp again?

That's the only idea I have at the moment.

Matthew