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 15:22:48 -0800 Message-ID: <5689AD48.4040902@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> <568966D4.5080707@dancol.org> <56898C6F.4010303@cs.ucla.edu> <56898EBD.2000000@dancol.org> <5689AA89.4030404@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="VoVrktxSr1qONqNDILH9SXK19e58hmbk6" X-Trace: ger.gmane.org 1451863408 26809 80.91.229.3 (3 Jan 2016 23:23:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 23:23:28 +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 Mon Jan 04 00:23:17 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 1aFrzX-00021L-Jv for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 00:23:15 +0100 Original-Received: from localhost ([::1]:43203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrzX-0000Oz-0E for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:23:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrzI-0000Ok-S3 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:23:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFrzE-0006Km-Rc for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:23:00 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFrzE-0006Ke-Gk; Sun, 03 Jan 2016 18:22:56 -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=6m82TK44ryj1IueO0+wJE//gSUoQRhM+oD9BvGHzKAk=; b=afqDuc6UzpJNH6YkEmI4A5nm56IkMb3ttmdAmvmsnsPGK1mv4q9wWLZJQtgzRaI4j2rWzx4hJzYM5d/sbn5/Nw1rCFzU2dt2MWjKc/Jx3zk00fA0TChjsn/ti46y8kYCd/ep+q3rtKkW9Dumw00jL8DEjCpdkcK2H51Dsf5GTeUBvJuzDJR4wFIx9QnPzVHZdH3wxUVj3q5g3uhjIdTQFkM0+n0q7f8txz4XGzUYho6w0ILyIaxGL976W6KqegLubwtraLjMe5d7Ofs7uHFoAiuA/lnBQDsCL6GOSR4KmG+dugBXr1/khpgCKWZssXfuPZTJedUSF3NUkw3focDu2w==; Original-Received: from mobile-166-176-184-191.mycingular.net ([166.176.184.191] helo=[192.168.43.34]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFrzD-0007x9-Rr; Sun, 03 Jan 2016 15:22:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <5689AA89.4030404@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:197524 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VoVrktxSr1qONqNDILH9SXK19e58hmbk6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/03/2016 03:11 PM, Paul Eggert wrote: > Daniel Colascione wrote: >> It's *critical* not to violate the invariants of code. >=20 > Sure, but we are discussing what those invariants should be; they are > not carved in stone. One possible invariant is (A) "stack overflow > never happens". Another is (B) "if stack overflow happens, callers must= > tolerate being longjmped through". Either invariant is reasonable per > se. It is a judgment call as to which invariant is better for Emacs. > Possibly some modules will prefer (A) and others (B). >=20 > Take the regular expression code as an example. Suppose it has unusual > worst-case behavior that can grow the stack in arbitrary ways (which I > think it does though I'm not going to investigate the details right > now). One way to address this is to rewrite the code so that it doesn't= > have the behavior, but that would be a pain; the code has been that way= > for decades and is crufty at this point and a lot of Emacs depends on > its quirks. Another way to address it is to use a guard page or whateve= r > on the halfway-decent platforms that support that sort of thing. We've > chosen the latter, i.e., we've chosen invariant (B), and yes there are > problems with this approach but it beats doing nothing and it beats > doing (A) because nobody has had the time to do (A), assuming it's > doable at all. The regexp code is a good example of a benign use of longjmp. That's our code and we know it pretty well. We can set a global variable that says "longjmp if there's a stack overflow in *this* piece of code" without longjmping out of arbitrary pieces of code we don't own. GDB uses a similar approach to suppress crashes from C++ demangling code. >> It should be possible to replace the printfs >> in this instance with calls to write(1, "message") (which will bypass >> any output buffering) and restore async-signal-safety. >=20 > Good point. I did that with the attached patch to emacs-25. However, > this doesn't address the Fdo_auto_save () issue in the same neighborhoo= d. Thanks. The quick and dirty fix for Fdo_auto_save is to run Fdo_auto_save in a forked child, where it's less likely to hurt something, and put a limit on the time we're prepared to spend waiting for that child. I've implemented Breakpad extensions that use a similar approach to good effect. Of course, this approach won't work for Windows, DOS, etc., but we're talking about quick and dirty. >> If a user elects to attempt auto-save in this situation, that's on him= =2E >=20 > Sure, and Emacs already asks the user whether to auto-save in that > situation, so this should be OK already. I'm not sure users on window systems actually see these prompts. IME, that's the majority of users. >> Ideally, we'd make autosave async-signal-safe, which will help in this= >> handler and in the segfault hander. >=20 > Yes, that'd be good, if we didn't lose functionality thereby. It's the functionality loss that prompts me to propose a simpler, pure-C, non-Fdo_auto_save approach to saving data when we're crashed; see the other branch of this thread. --VoVrktxSr1qONqNDILH9SXK19e58hmbk6 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 iQIcBAEBCAAGBQJWia1IAAoJEN4WImmbpWBlAOAP/0L5ll2xPrUIVB7ji7Gky/2v /ZVpDr8Af4Km04SDyPvUPxJ5XNZJu0p1rK4J6ZzqWgpXyatNoGiv3dv3cloE5HvO 21aXD/GZ8gwZNrH9sDgPad4KY0fBqhXNzRFQ9OBNpxZhsouPgh0DcHQqr1u+f71e Y8q/xF8fEagEPKaks7pLhhQOTAkV8+t9/aGsSxllr0rUlIkt2Uae4WOc40aFOHVa SljipwAvmkdaqV5oqyRwzetBjrziSmfeEeh+HCBpOtHSNSKh07XcFH3bdC2KDvIN 0tDoBAwBeSx6Z4fyyKY1lEs0JtfvZ7fMavaYvaWLhMuaJdcH+wPKjgTLXkCQaMJf 2Hc83WWVKuiyH6gN/tcDMfOj34rhgrwKUbmYxFW+3xd+/p3dCe43ewB1eQlqi87K Lo0OZrchbT9gF8YPSVyecy1T5e98TCi/S1Hxg52vqz8ygAPFtm5TRWWGgLaXFmQz 4gY3hfHLobBjSxlrKPQVxdZUCHFN4wcUEL4lDGXn9Y9SKIxPh26YzOGpeDibauCx IB9UBZ6IoWjZdq5m1m+S1xUrfbDAm6020BlDk1zSmqgjLQYcLL4inIFeK4hvWKYQ bY3+R+Sdc8+fL0bccBtDZKPJw/tURb0aXA52I7RnTo+AK1aOrIASqEjjHDdjoNeT 4yj8b9m4Tk2o556CdM6O =Cs6a -----END PGP SIGNATURE----- --VoVrktxSr1qONqNDILH9SXK19e58hmbk6--