From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 21 Dec 2015 10:28:09 -0800 Message-ID: <567844B9.2050308@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <83io4nuc68.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gJ8Ii5MmxrsX3G9Oqt3oglKdqKpsbWO1X" X-Trace: ger.gmane.org 1450722528 11546 80.91.229.3 (21 Dec 2015 18:28:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 18:28:48 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 21 19:28:46 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 1aB5CP-0006bm-Eo for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 19:28:45 +0100 Original-Received: from localhost ([::1]:46764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5CO-00040y-OL for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 13:28:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5C9-00040l-5W for emacs-devel@gnu.org; Mon, 21 Dec 2015 13:28:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aB5C4-0002y1-Ok for emacs-devel@gnu.org; Mon, 21 Dec 2015 13:28:27 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:51500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5C4-0002sF-DF; Mon, 21 Dec 2015 13:28:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=8RBkWXUq8PyoSeRDc+zLuZTkzW++ZpFSakf3EY5delk=; b=fJapGcsZunVnFePAjQwEW9mgxaSYvkHNfu8AeQsnXgDXEgEwml89lEbeZc3ILP+DKjd/GvXf7BbdeWrfkGKACVB12/Qru52ngHHcoEggLSC1yBigMLMkha3qn5eZoAm3dPo+5XSQKDiYk9ASa3Zgr4cCOs8g39v2eNkZImD7aUen4j+6qe2XuqwxK/baBn8O+KplFOys/8wf+4XKiu7PiFazJrOjgldkr3wgFrW33BPiC+MdIkajqxco5312oGcqjkNMJuqXjYC8Orv7gXzOCnXhGAFjKpORLTk6yH3qiyxcx/1HN4TPTq9f+MxBaj2+loEACE+rY/iSKxepIMWj5w==; Original-Received: from [2620:10d:c090:180::1edf] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aB5Bw-0000xh-SK; Mon, 21 Dec 2015 10:28:16 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <567841A6.4090408@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:196621 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJ8Ii5MmxrsX3G9Oqt3oglKdqKpsbWO1X Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/21/2015 10:15 AM, Paul Eggert wrote: > Eli Zaretskii wrote: >=20 >> Are you >> now saying something different from what you said back then, i.e. that= >> we cannot rely on any function/macro from lisp.h to be signal-safe? >=20 > Yes and no. As I understood it, that old conversation was about > functions that explicitly signal or throw, and it's safe to assume that= > EQ, NILP, etc. won't do that. The new conversation is about running out= > of memory, which is a different form of non-local exit.=20 IMHO, we should treat OOM exactly like other sorts of error. It's dangerous to make some functions infallible. > There may be > other forms, such as operating-system signals (I don't recall exactly).= OS signals should go through the usual Emacs event loop, right? >> If so, we should add the necessary protection, in the form of calls to= >> MODULE_FUNCTION_BEGIN, to emacs-module.c functions that until now >> relied on those lisp.h functions/macros to be safe. >=20 > This wouldn't suffice for these other non-local exits, I think; at > least, not as currently constructed. >=20 >> AFAIK, proper C++ exception handling >> requires non-trivial amounts of stack space that is not available when= >> there's stack overflow, where you have at most a single guard page to >> work with. >=20 > There should be workarounds for that. Surely the C++ community has run > into this problem and has solutions. If we want to support C++ modules,= > we need to employ them. The standard requires runtimes reserve enough memory to throw std::bad_alloc. All Emacs has to do is make sure control flow reaches the C++ level. >> I think there is some misunderstanding here, or some confusion, >> perhaps mine: emacs-module.c is not supposed to deal with any C++ >> exceptions. C++ exceptions are supposed to be caught at the C++ >> level, below emacs-module.c, and handled there. An exception that >> isn't caught will be recorded and will cause all the subsequent calls >> to Lisp or to emacs-module.c function to fail, >=20 > Why bother? If C++ exceptions are supposed to be caught by the C++ > module in question, why does Emacs need to worry about C++ exceptions > that are not caught? IMHO, it should be the module's job to make sure C++ exceptions don't propagate through Emacs stack frames. Emacs shouldn't know or care about C++ exceptions in any way. You previously wrote that, > If emacs-module.c or the Emacs exception-handling mechanism really > needs to be rewritten in C++ in order to catch C++ exceptions nicely, > then somebody with C++ expertise should do that. I think there's a fundamental misunderstanding here. Emacs signals and C++ exceptions are completely separate mechanisms. There's no reason Emacs has to care about C++ at all. When we say that we want C++ exceptions to work, the Emacs-relevant meaning is that Emacs should return always use conventional local returns, not longjmp, so that the stack unwinding facilities of other languages (e.g., C++) work properly. >> What emacs-module.c does with non-local exits of _any_ kind is record >> the first occurrence of such an exit, and silently return to the >> caller, thus allowing the C++ objects on the stack to be destroyed >> normally. IOW, it defers the exit until internal--module-call is >> about to return. What problems do you see with that which cause you >> to think it's error-prone, let alone dysfunctional? >=20 > It uses a different model at the C level from what one sees in Elisp, o= r > from what one normally sees in C for that matter. I don't feel that I > will really understand the model unless I see some actual modules that > do function calls and exception handling; but it's hard to believe that= > a model that does silent returns and that defers returns until later an= d > that records some returns but not others will be problem-free. Wouldn't= > it be simpler to have a module invoke analogs of 'condition-case' and/o= r > 'catch', and to dispense with the funcall_exit stuff? >=20 Both the Python and Java extension APIs implement high-level exceptions with low-level state exactly the way we're talking about here, and the result has been generally usable. Of course it's possible for module authors (or Emacs developers) to introduce bugs with either model, but using an explicit error indication results in bugs that are easier to notice and easier to fix. --gJ8Ii5MmxrsX3G9Oqt3oglKdqKpsbWO1X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWeES6AAoJEN4WImmbpWBl7wUP/RWv2JFqPx8vSkwT0jgy505V BgEWCJx8DBYs7EMR7b5HIu5mTQRN5Nr1plllS3vNCE0D7dAtNL1UIf2ovJD387v9 jti76rgi4wC5FwLUz+BP+0TSkJILTWlEmnerW+d4nz9m/qOVifyAyhDyYGU3sgN6 zIBOuYaOFy4nm6hPFBzTgsth4tkKsWyvgnZvgtY4FNNZ5LH8n+UUx+t2mV45dC5o PJUg8lW0AcJYxc86zzVOAkqNID8nh1lSc3MuMQBSRKZGAgPKot+BO5Tw0SJ1qg53 ztdes3PNMVzCQe79va5ET3BR3A0GWJod/Fpa0W4EROIPyplhtd9u2x6nQc8Vq5R5 WaBa5srqa0LRH0jnJ85F9IvCW10NMpYISbI7+fEgAUtcej936rUHShz+7QBbtwsD zj7v9T9tl1GFQWSGMb0b+xfFEEd+P+SRLOfupl0hkp0SmwI3rLCNDORu8gQy2AVR 36cUJG5DTccrNu+0gduCLgFSJFf9nsSrgjkUUHQgtYuRbIhI+2K8IbUSVVYBwhH9 znj7oeraW+ZmNjMCLhbkoLXunhYsk6stPpziOB3lCX/o1Xl5hadiCP9OUwzxC34I /0b8BfXXeo8yerL7nRTdtPk8BSKPwWM0+MKf8c8E5Xr7jDz+pIySbdd6/nY5MY75 UpSmGa4loDFgmg9jCvor =Fyz1 -----END PGP SIGNATURE----- --gJ8Ii5MmxrsX3G9Oqt3oglKdqKpsbWO1X--