From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: DSO-style DSOs (this is NOT an FFI!) Date: Thu, 10 Oct 2013 13:36:25 +0900 Message-ID: <87pprdivxy.fsf@uwakimon.sk.tsukuba.ac.jp> References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> <87fvsdpato.fsf@flea.lifelogs.com> <8738oc20xk.fsf@flea.lifelogs.com> <87d2ngzlyl.fsf_-_@flea.lifelogs.com> <87siwcxda7.fsf@flea.lifelogs.com> <87zjqjfz36.fsf@fleche.redhat.com> <87wqlnv9bn.fsf@flea.lifelogs.com> <52546F55.1020707@lanl.gov> <87bo2yt70v.fsf@flea.lifelogs.com> <5255EC44.4070203@lanl.gov> <87wqllsyr0.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1381379808 7899 80.91.229.3 (10 Oct 2013 04:36:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Oct 2013 04:36:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 10 06:36:52 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VU7zX-0004WH-Gz for ged-emacs-devel@m.gmane.org; Thu, 10 Oct 2013 06:36:51 +0200 Original-Received: from localhost ([::1]:44850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU7zW-0002RT-U2 for ged-emacs-devel@m.gmane.org; Thu, 10 Oct 2013 00:36:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU7zN-0002QX-C9 for emacs-devel@gnu.org; Thu, 10 Oct 2013 00:36:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VU7zG-0005aK-1M for emacs-devel@gnu.org; Thu, 10 Oct 2013 00:36:41 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:53488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU7zF-0005Ze-Gx for emacs-devel@gnu.org; Thu, 10 Oct 2013 00:36:33 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9F9DB3FA0A12 for ; Thu, 10 Oct 2013 13:36:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 977C0120619; Thu, 10 Oct 2013 13:36:25 +0900 (JST) In-Reply-To: <87wqllsyr0.fsf@flea.lifelogs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164054 Archived-At: 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.