From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Tue, 29 Sep 2015 15:04:35 -0600 Organization: XCP-1 Message-ID: <560AFCE3.8090802@lanl.gov> References: <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> <22025.61338.681227.470671@turnbull.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443649478 7537 80.91.229.3 (30 Sep 2015 21:44:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 21:44:38 +0000 (UTC) Cc: Paul Eggert , Daniel Colascione , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?ISO-8859-1?Q?Aur=E9lien_Aptel?= , Tom Tromey , Stephen Leake To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 30 23:44:28 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 1ZhPAp-0003Pb-9N for ged-emacs-devel@m.gmane.org; Wed, 30 Sep 2015 23:44:27 +0200 Original-Received: from localhost ([::1]:33764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhPAo-0006DM-I9 for ged-emacs-devel@m.gmane.org; Wed, 30 Sep 2015 17:44:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh253-0004ob-Qw for emacs-devel@gnu.org; Tue, 29 Sep 2015 17:04:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zh250-0001lI-Iu for emacs-devel@gnu.org; Tue, 29 Sep 2015 17:04:57 -0400 Original-Received: from proofpoint5.lanl.gov ([2001:400:4210:400::a5]:52530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh250-0001kj-9R for emacs-devel@gnu.org; Tue, 29 Sep 2015 17:04:54 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id t8TL4ZYF005328; Tue, 29 Sep 2015 15:04:35 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id E7AC6139A527; Tue, 29 Sep 2015 15:04:35 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from xray-r08.lanl.gov (xray-r08.lanl.gov [128.165.123.189]) by mailrelay1.lanl.gov (Postfix) with ESMTP id CC14B139A175; Tue, 29 Sep 2015 15:04:35 -0600 (MDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110717 Lanikai/3.1.11 In-Reply-To: <22025.61338.681227.470671@turnbull.sk.tsukuba.ac.jp> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-29_14:2015-09-29, 2015-09-29, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:400:4210:400::a5 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:190489 Archived-At: > I don't see what else can possibly work, since if you set a condition > case in the API calling into the module (ie, in [main Lisp]), you've > already hosed the called code by the time you handle it. What if we avoid the longjmp call rather than catching it? Define a (thread-local) signal-raising hook which is also a specpdl barrier. A C++ client, for example, could write (perhaps with some added 'extern "C"') namespace { struct emacs_exception : std::exception { emacs_exception(emacs_value e,emacs_value d) : error(e),data(d) {} emacs_value error,data; }; void die(emacs_value error,emacs_value data) { throw emacs_exception(error,data); } emacs_value my_subr(emacs_env *env,int nargs,emacs_value args[]) { env->error_handle(env,die); // creates barrier try { std::vector data; // to be cleaned up env->funcall(env,/*...*/); } catch(const emacs_exception &e) { // various variables assumed to be already obtained elsewhere if(eq(e.error,Qfile_error)) { /* handle file-not-found */; return Qnil; } else env->error_signal(env,e.error,e.data); } return Qt; } } Then Fsignal/Fthrow can do its cleanup down to the barrier, then call the hook. The exception unwinds the stack back into the C++ module, does appropriate destructor things, and then is caught before the module returns to Emacs. There, the module can choose to return normally (thus acting like condition-case) or propagate the error (thus having its destructors act like unwind-protect). Here we have the overhead of error_handle only once per call from Emacs into the module rather than on each call from the module into Emacs (probably larger). We might be able to avoid even that by putting the handler into the emacs_env, but that would lose the flexible barrier placement and presumably Fsignal still has to consult a how-to-signal variable that would have to be set at least once per Emacs->module call. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.