From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 14 Sep 2015 09:36:10 -0500 Message-ID: <864mix5aqt.fsf@stephe-leake.org> References: <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442241697 2838 80.91.229.3 (14 Sep 2015 14:41:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 14:41:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 16:41:26 2015 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 1ZbUwe-0005kj-9C for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 16:41:24 +0200 Original-Received: from localhost ([::1]:41358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbUwd-0000kc-H4 for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 10:41:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbUw8-0000i2-Tn for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:40:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbUro-0005p4-OI for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:36:29 -0400 Original-Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:40068) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZbUro-0005fm-HU for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:36:24 -0400 Original-Received: (qmail 24221 invoked by uid 0); 14 Sep 2015 14:36:18 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 14 Sep 2015 14:36:18 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id H2cD1r0132UdiVW012cGQb; Mon, 14 Sep 2015 08:36:17 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=ff-B7xzCdYMA:10 a=jBJDzpcClqeTmYzUZEwA:9 Original-Received: from [76.218.37.33] (port=51693 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZbUre-000754-0N for emacs-devel@gnu.org; Mon, 14 Sep 2015 08:36:14 -0600 In-Reply-To: (Stefan Monnier's message of "Mon, 14 Sep 2015 08:14:06 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.20.122 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:189945 Archived-At: Stefan Monnier writes: >> Yes, but the whole point of the module system is to access non-Emacs >> libraries, > > But the issue only comes up once these non-Emacs libraries call back to > Emacs functions (i.e. step 5 in my example). So only those calls need > to be protected somehow from non-local exits. I think Daniel's point is that most module developers will not be aware of this issue, and will be totally lost when it occurs. In addition, how many libraries document whether they are "longjmp safe"? I suspect that actually depends on compiler options, so it's up to the packagers to ensure it. Imagine someone used to writing Java code, with the attitude "the language is totally safe, I don't need to worry about details"; now they try to write an Emacs module, calling out to Java code all over the place. Chaos ensues, and Emacs gets another bad wrap as "unusable". So if the Emacs module API can be made to support those developers, it would be a good thing. I think his point is valid, although it would be nice for expert module developers to be able to bypass the "safe call" if it becomes a performance issue. I don't think we can make writing an Emacs module as easy as writing a Java class, but we should consider doing as much as we can to make it easier/safer for the novice. On the other hand, being forced to handle an exception instead of remembering to check a status code is a proven win. So perhaps there is a way to make all module developers aware of this issue; a well written, short "module developer's checklist" would help here. >> Imagine if you had to individually arrange to call free on both the >> success and error paths for every string you wanted to allocate --- >> that's what life will will be like for module authors. > > No. Only for those who choose to use use manually-managed data. Some module authors won't realize they've chosen that. -- -- Stephe