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 13:31:49 -0800 Message-ID: <56899345.2040005@dancol.org> References: <83mvu1x6t3.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> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P60uDWvKBxHNpJfHOUen1Jle8FxPjfsIW" X-Trace: ger.gmane.org 1451856722 28709 80.91.229.3 (3 Jan 2016 21:32:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 21:32:02 +0000 (UTC) To: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 22:32:01 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 1aFqFs-0004HL-R7 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 22:32:01 +0100 Original-Received: from localhost ([::1]:43000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqFs-0008FN-08 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 16:32:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqFo-0008Ei-Fy for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:31:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFqFn-0002tA-IK for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:31:56 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFqFn-0002sy-Bw; Sun, 03 Jan 2016 16:31:55 -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=RVm9eRsuXUNMcQwgWqXBN720FNV7ORtJJhbaKyQNsi8=; b=DnlRgJr3VzpL//UL6YRK2iSQkUUOU55b38/fSGYDwWtLi0wvbCJQSGAlY1kRGhXUlAGmoGVk3tdyCRMD/RgaxJwoH4dcG3+5an7/Dwkzew6DRjuXmk8MngVgkwrAIk15LhxOwNw/tYM0OVs9k76G8pYbyE2guehpcVbx7igWFC+aWYfN98uVPwvqYDI9xjZXrN3XT9hcgD3UbglNfj+MPZ8FCefJfJyhTpS8oqBJJDy8qThffF9GPr/wM0Q+78r1gWVrSc1A+pERIAhvnqD9/O9cgeHd3rznTx0je0JDy6KLuvhCDcC4zOOhhJL6KvRbEryOMbBRgFZsAtLirxxUzQ==; Original-Received: from [2620:10d:c090:180::1:692e] (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 1aFqFm-0007Nh-VF; Sun, 03 Jan 2016 13:31:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <56899278.9000007@dancol.org> 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:197507 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P60uDWvKBxHNpJfHOUen1Jle8FxPjfsIW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 01:28 PM, Daniel Colascione wrote: > On 01/03/2016 01:07 PM, John Wiegley wrote: >>>>>>> Daniel Colascione writes: >> >>> It's not just a theoretical problem: I've spent lots of late nights s= taring >>> at stack traces, trying to figure out how a certain deadlock could be= >>> possible, only to realize that the program had already crashed --- or= would >>> have, if a seldom-tested bit of code hadn't checked for NULL and retu= rned >>> without releasing a lock, causing a hang half an hour later. >> >> I see. Isn't what you describe an argument against error handling in g= eneral, >> though? It too can mask the origin of serious problems. >=20 > It is. There's a difference between trying to paper over undefined > behavior generally, however, and reporting well-defined errors using a > safe mechanism. (The former invalidates the system's own invariants, > while the latter invalidates only the application's invariants.) >=20 > But yes, error handling in general can paper over bugs, and I've > certainly seem Emacs bugs similarly exacerbated by attempting to ignore= > errors. >=20 >> What if we do this: >> >> 1. When a serious error occurs that engages crash recovery, we pop u= p a >> window in Emacs describing that a serious error occurred that wou= ld have >> crashed Emacs --and that *nothing* should be trusted now. All the= user >> should do is save critical buffers and exit immediately. >=20 > The call to Fdo_auto_save tries to do that already. Fdo_auto_save isn't= > async-signal-safe, so I'd rather fork a child process, in the child, > call Fdo_auto_save and exit, have the parent wait 500ms for the child > (not forever, in case the child deadlocks), kill the child, and continu= e > crashing. That, or provide a less elaborate, async-signal-safe, pure C > auto-save facility. I'd also support doing no auto-save at crash time. Auto-save should happen frequently enough anyway that users shouldn't lose much data when a crash happens, and not auto-saving sidesteps a lot of robustness concer= ns. --P60uDWvKBxHNpJfHOUen1Jle8FxPjfsIW 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 iQIcBAEBCAAGBQJWiZNFAAoJEN4WImmbpWBlJOkP/i+8vP7vAYtby+sYCAhO24oN XH3yNwBBKTiNfvYr2hEnpAaVUvcKVpUipOnJG0PWOhaEqQvWK/W85u051zvQ0uFi m0Ye2RgtdmTXbvOluUQy53nxTydYP0Xo5scp4/QuMOfXyxRKROU/v7XIyZWGEy1C f876M32k8pdVAQQNftzQ/rUiYKSFYgiPjt5MVhbO0t20rYc9ZOEHlVF07Rpx5WKb kOTFc0zEIrFlFnCQAxqjmRlX+8MZZ39wfHRWUgn73MuxwPkBVqmJKyU7u1dYx3rB AwzQFlucshF3Si/Dhx7YgpsE9FlsAJIuhakqxCf1VRNpacbVVS67a3bKpo0z3FXU y27IXR6kEZ3QonCyDpsgmI8qldKT0q6pWGD2uf7Z3ogufq+qz0d1ANILa6TeBoj1 rmkBPG30ZTVHfT/yK/geanOcMnvIppit888X3W2syzLJldYs+Gz7GXK+LnTGEoz4 0Ut6G861eClf4GA/edUa0l/cgUJ/Bpwg/+vXIpUDRMk8cqKSNOZ23/Df4XwUsQnZ PQhmiE16VLIFEKLe+TSTaw50y0ZRMijkaYoiVf6DT/GKVtPYv02Q2yVsXe8fTWFO qP8POAPNJ7OeE0BXwy2OD0S72863NkD7mqXInjB9KEDayIIcn4td7ORr3yU5WsEe xIl04QbOnFab0oAZNl3Z =T6/4 -----END PGP SIGNATURE----- --P60uDWvKBxHNpJfHOUen1Jle8FxPjfsIW--