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: Sun, 3 Jan 2016 10:22:12 -0800 Message-ID: <568966D4.5080707@dancol.org> References: <83mvu1x6t3.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> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <56894CE7.7090301@cs.ucla.edu> <568950C5.2030306@dancol.org> <56896359.4020309@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="1SnCJcOiaDrgedrc7QVqSqiRj5MVXN7uc" X-Trace: ger.gmane.org 1451845366 27591 80.91.229.3 (3 Jan 2016 18:22:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 18:22:46 +0000 (UTC) To: Paul Eggert , Eli Zaretskii , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 19:22:37 2016 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 1aFnIa-0005Gy-F8 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 19:22:36 +0100 Original-Received: from localhost ([::1]:42474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnIZ-00089m-QP for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 13:22:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnIL-00089f-DG for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:22:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFnIG-000734-DG for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:22:21 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnIG-000730-1z; Sun, 03 Jan 2016 13:22:16 -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:References:To:Subject; bh=A3cfupB7WlO0JkUYXEJidLQWaM3/1ukZdaSwXVgMOEs=; b=GLUH5pudF+9RBV8RrDqkRN+bt8D8+Ts+DdzAZzNUj5sazBn+xoXAD6QEBfD0oghVZqlseM8SailyrQ293MjtxSSLvptEIG3ZqGaqwvLg4jObkYg+Lw2rSjjWJVkcREyRYZjaOvXWTjWxaEXpEpibL1wPkwgPigu7X1nH/dke2/BiDslWqbx+Z0ZznGrjeehk5K8cuNHxp9+1RWleauv5dGWdwsbVA7rKRDCfXeOlAII45WzW15YEinHeBwqLCItlK2KZEGyH9y2AyBw2CXtvxeiAowol/QROA/p1qQ07NuzLutlovU0CER1Dr4stGoFZu/uMbZ5zmHqsWw01je2/jg==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFnIF-0006O8-Lj; Sun, 03 Jan 2016 10:22:15 -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: <56896359.4020309@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:197481 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1SnCJcOiaDrgedrc7QVqSqiRj5MVXN7uc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/03/2016 10:07 AM, Paul Eggert wrote: > Daniel Colascione wrote: >=20 >> we don't respond to *unix* signals by longjmping. >=20 > Not true. A code path is deliver_interrupt_signal =E2=86=92 > deliver_process_signal =E2=86=92 handle_interrupt_signal =E2=86=92 hand= le_interrupt =E2=86=92 > quit_throw_to_read_char =E2=86=92 sys_longjmp. Not the case. handle_interrupt can call quit_throw_to_read_char only when waiting_for_input is true, which it is only when, well, we're waiting for input, not at arbitrary points in the program. It can't be the case that we can longjmp from arbitrary points in Emacs in response to a SIGINT, since if we did, C-g would be unsafe and could crash Emacs, which it doesn't. > For what it's worth, Emacs can > also lisp-signal from Unix signal handlers if immediate_quit is true. > This code has been in Emacs for many years. Likewise. Any call to malloc (or, in general, any async-signal-unsafe function) with immediate_quit or waiting_for_input true is a bug that we need to fix. Longjmp from a signal handler isn't a bad approach. I use it in my own programs. It becomes abominable when the longjmp can happen from *anywhere*, as it can with the stack overflow handler. >> The libsigsegv approach is a problem too: pthread cancellation in >> practice is unsupported on some platforms, does not execute C++ >> destructors on some platforms even where it's supported, is lightly >> tested, and conflicts with other uses of sigsegv. In the case of Emacs= , >> pthread cancellation is additionally risky because we don't even try t= o >> PTHREAD_CANCEL_DISABLE around critical code sequences. >=20 > Yes, of course we'd have to do some work to take the libsigsegv > approach. We would need to use pthread cancellation only on platforms > where it works, and we would need to defer cancellation during critical= > sections. On platforms that lack pthread cancellation or where it > doesn't work, we'd be no worse off than we are now. If we do the longjm= p > ourselves I assume we can work around the C++ destructor problem the > same way we do now. Or can we use a stack guard region [1], and in the signal handler, unprotect the set a global variable in the signal handler, and check the variable on QUIT, and at toplevel, reprotect the guard region. If we segfault again without having reached toplevel, just die. Would that make you happy? I'd much rather see that approach, which is safe, than our current one, which isn't. [1] If I say "guard page", the conventional term, you'll complain that a single page isn't sufficient. > From what Eli writes, some of this work (I don't know how much) has > already been done for the MS-Windows port. It would be helpful to do > something similar for GNU/Linux and similar platforms, and to do it > right by marking critical sections etc. All this would make Emacs more > bullet-proof, if someone has the time to undertake the job. I haven't looked as much at the Windows stack overflow implementation, but there's clearly nothing in the code right now that establishes the critical regions necessary for this scheme to work. Besides, this scheme *still* leaves you vulnerable to stack overflow, since if you overflow in a cancellation-disable region, your only option is to crash. Again, neither you nor Eli have demonstrated in any way that all this complexity is necessary, that we actually have a C stack overflow problem, or that we have special needs that other text editors and user programs don't, needs that justify an elaborate stack overflow recovery scheme. --1SnCJcOiaDrgedrc7QVqSqiRj5MVXN7uc 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 iQIcBAEBCAAGBQJWiWbUAAoJEN4WImmbpWBlD/sQAJUSbws8GLS3DULJ7KYUDKJt iSrhUwzybDySREUjSUXpPwsih4zNpqD/tDfJgoiSAyP4R1wobHzERye1sMwOUQOQ 89GX/KpNwrZT1PYwBYtUlnedNttlhMmuoav9EIunBuFafKJjX0a0U2NQb4P0Yf99 ozs3FVqOi/CGVWTZJP1Yn5+XbHyC2lBS1SUkNnk/hXCMcQebmaECOPdg8heO2EQV tV2AzarXHdDm9LNAzoVPqVBXSDkLq5U3yNfF6YAcJKI9gPKn0MtX1j0SizqrdAsq x+jZ6qm0RQGAHr6euNLLrC+0XWREWnfenLrQLIuHnkKxwgo2Jo8EQpFQewm0dS78 cVCg91cn8RX2vCd83dU3NAwxGXDuMUD+E7jK6VZ2nqLDO3TiTYKXTKuKxqQPjDwy PaejTU45jafARCr/D5LsmkR30GqruarFjymoOV1ViPUE88x/DzydVB4nhTPxp1UN 2Lh23gLVnZOyGnyGXhCvPdM1cwAUqDSMi3wl2bW/8Ol6a9ahTPCtRPunzISuy8J/ LccGy6hwzOLIx9RxyET3jF51EVQ8GgoQMeyCq9jsqXfwZ2n1GVfKFEtLokBu8vlj oIGFR5qwA0xs1D7g/EXJM1SeAWns42QHDfZkeau/0B4OH5HN08A7XOmqT8UbwXRO MDoCs3o+d0LzHwAzrRKX =RkPo -----END PGP SIGNATURE----- --1SnCJcOiaDrgedrc7QVqSqiRj5MVXN7uc--