[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DSO-style DSOs (this is NOT an FFI!)
From: |
Stephen J. Turnbull |
Subject: |
Re: DSO-style DSOs (this is NOT an FFI!) |
Date: |
Thu, 10 Oct 2013 13:36:25 +0900 |
Ted Zlatanov writes:
> DH> As for accidental corruption, you can at least protect your Lisp_Objects
> DH> by controlling how you copy data into and out of them.
DSOs are no different from any other C code as far as data corruption
goes. You can't do anything more, and shouldn't do less, than you
could do if the code were linked into Emacs at build time. The advice
is "be a good Emacs C-level programmer, and you'll be OK."
The only reasonable restrictions are:
(1) Initialize the module with
if (this_module_max_gpl < this_emacs_min_gpl) launch_lawyers();
(if this_module_max_gpl is undefined, the link will fail, which is the
desired outcome :-).
(2) callbacks into Emacs must refer to symbols obtained from
intern(). You can't call extern functions or reference extern
variables directly.
The marshalling and unmarshalling implied by (2) needs to be done
anyway because these DSOs are intended to provide Lisp-level
functionality. (If not, there's no problem. Ask Eli Z about how
Windows does its "if-available" DLL loading.) It may as well be done
in the DSO so that intern() is the only rendezvous point needed
between Emacs and the DSO.
> Moreover, I was wondering whether the risk is acceptable.
If it's not, the implications for using any Emacs coded in C are,
well, *severe*. ;-) (The "maybe we're loading non-GPL 3d-party code
unknowingly" risk is an exception, of course. That's irrelevant to
language though -- I've always wondered why non-GPL DSOs are a risk
and non-GPL Lisp isn't. But let's not go there.... :-)
> The other extreme is to have some protocol to externally executed
> modules so there's no chance of corruption; it's very inefficient
> but also much less risky.
That may as well be a true FFI (ie, a way to bind Lisp symbols to
external objects from Lisp). If it's not, then the module programmer
is writing C, so: GOTO "DSOs are no different...."[1]
Footnotes:
[1] Emacs programmers are hardly exempt from the dictum "premature
optimization is the root of all error". The temptation to short cut
the protocol when writing C will be unbearable for some.
- DSO-style FFI (was: Emacs crypto use cases), (continued)
- DSO-style FFI (was: Emacs crypto use cases), Stefan Monnier, 2013/10/08
- Re: DSO-style FFI, Tom Tromey, 2013/10/08
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/08
- Re: DSO-style FFI, Tom Tromey, 2013/10/08
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/09
- Re: DSO-style FFI, Andreas Schwab, 2013/10/10
- Re: DSO-style FFI, Davis Herring, 2013/10/08
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/09
- Re: DSO-style FFI, Davis Herring, 2013/10/09
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/09
- Re: DSO-style DSOs (this is NOT an FFI!),
Stephen J. Turnbull <=
- Re: DSO-style FFI, Stephen J. Turnbull, 2013/10/08
- Re: DSO-style FFI, Stefan Monnier, 2013/10/08
- Re: DSO-style FFI, Michael Welsh Duggan, 2013/10/12
- Re: DSO-style FFI, Stephen J. Turnbull, 2013/10/12
- Re: DSO-style FFI, Stefan Monnier, 2013/10/14
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/18
- Re: DSO-style FFI, Stefan Monnier, 2013/10/19
- Re: DSO-style FFI, Stefan Monnier, 2013/10/19
- Re: DSO-style FFI, Andy Moreton, 2013/10/19
- Re: DSO-style FFI, Ted Zlatanov, 2013/10/19