[cffi-devel] protect C frames from Lisp non-local exits in callbacks
Stephen Compall
s11 at member.fsf.org
Fri Jan 6 16:15:04 UTC 2006
On Fri, 2006-01-06 at 10:30 +0100, Hoehle, Joerg-Cyril wrote:
> And the general answer is: don't exit non-locally across callbacks!
> It can always lead to unforeseen trouble.
After writing the callbacks section (see Tutorial-Callbacks in
http://csserver.evansville.edu/~sc87/cffi/tutorial.texi) I decided to
explore whether CFFI could (or should, even) provide a general non-local
exit prevention. The answer is, with some difficulty and an interface
change, perhaps.
On Lisps with EXIT-EXTENT:MEDIUM, this can be implemented with an
unwind-protect form in defcallback [1], which performs the operation
posted (as undefined in MINIMAL). Lisps with built-in protection in
callback definition don't need this.
> >As an aside: would it be better for the defcallback semantics to simply
> >say "don't exit non-locally through a C frame"?
> Exactly. It's the only sensible thing to do.
> Ideally, every callback should contain something similar to ignore-errors (e.g. X event loops).
The tutorial does this.
> >It would probably make
> >callbacks (and perhaps callouts, for that matter) cheaper to call,
> I don't understand that implication.
If CFFI is to provide general unwind prevention as stated above, the
EXIT-EXTENT:MEDIUM would entail the overhead of always entering an
unwind-protect. In addition, if one wanted the "other side" to signal
an error indicating that Lisp tried to unwind a C frame, a flag check
would have to be added to every foreign funcall. [2] I don't, but the
possibility remains.
defcallback doesn't provide this now, and maybe shouldn't at all. In
the tutorial, a value must be computed and returned to indicate an
error; a parameter would have to be added to defcallback to do this,
assuming you care whether C knows that there was some error.
[1] This does not protect you from non-local exits in the handler code,
as that would entail another unwind-protect, which itself would have
unprotected code ... however, it protects all of the important part --
user code.
[2] Not really important when you're doing a bunch of generic function
calls under cffi-new-translators anyway, I suppose.
--
Stephen Compall
http://scompall.nocandysw.com/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20060106/7a465a75/attachment.sig>
More information about the cffi-devel
mailing list