summaryrefslogtreecommitdiffstats
path: root/ffi.c
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2019-02-07 23:14:35 -0800
committerKaz Kylheku <kaz@kylheku.com>2019-02-07 23:23:55 -0800
commit124f3c016898056c3c4e3e9d67d1e5288b837b15 (patch)
tree5500119776ae9a90081e311108f495490b64f36d /ffi.c
parentb4bfaec54640ef51accbd4e2470951036bf6cbe8 (diff)
downloadtxr-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.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/ffi.c b/ffi.c
index e0f662b3..0b119486 100644
--- a/ffi.c
+++ b/ffi.c
@@ -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;