diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2019-02-07 23:14:35 -0800 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2019-02-07 23:23:55 -0800 |
commit | 124f3c016898056c3c4e3e9d67d1e5288b837b15 (patch) | |
tree | 5500119776ae9a90081e311108f495490b64f36d /ffi.c | |
parent | b4bfaec54640ef51accbd4e2470951036bf6cbe8 (diff) | |
download | txr-124f3c016898056c3c4e3e9d67d1e5288b837b15.tar.gz txr-124f3c016898056c3c4e3e9d67d1e5288b837b15.tar.bz2 txr-124f3c016898056c3c4e3e9d67d1e5288b837b15.zip |
ffi: closure: clear stale saved exit point.
What happens if a FFI closure intercepts an exception, returns
to the foreign code, but that caller does not return to Lisp
where the exception will continue? Suppose the caller invokes
another closure. In that situation, the lingering value of
the s_exit_point variable causes problems for FFI calls.
An example of this is callbacks from an event dispatching
framework such as a GUI. When these callback closures return,
control returns to the event loop, which itself doesn't
immediately return to Lisp code. Rather, it processes more
events and invokes more callbacks.
* ffi.c (ffi_closure_dispatch_safe): One thing we can do
is clear s_exit_point whenever we dispatch a closure.
Diffstat (limited to 'ffi.c')
-rw-r--r-- | ffi.c | 2 |
1 files changed, 2 insertions, 0 deletions
@@ -4179,6 +4179,8 @@ static void ffi_closure_dispatch_safe(ffi_cif *cif, void *cret, if (rtft->release != 0) memset(cret, 0, rsize); + s_exit_point = 0; + uw_push_guard(&cont_guard, 0); uw_simple_catch_begin; |