From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Tue, 22 Dec 2015 17:26:14 +0000 Message-ID: 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> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <5678D710.9010406@dancol.org> <5678E8FE.1010502@cs.ucla.edu> <5678EA4E.6080606@dancol.org> <83io3qqx7s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1148e7109fa43305277fe768 X-Trace: ger.gmane.org 1450805390 26561 80.91.229.3 (22 Dec 2015 17:29:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 17:29:50 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 18:29:43 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 1aBQkm-0004GO-DY for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 18:29:40 +0100 Original-Received: from localhost ([::1]:52156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBQkl-0008Hz-Tc for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 12:29:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBQhf-0003RM-NI for emacs-devel@gnu.org; Tue, 22 Dec 2015 12:26:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBQhe-00014X-GU for emacs-devel@gnu.org; Tue, 22 Dec 2015 12:26:27 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:36904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBQhc-00012y-Fr; Tue, 22 Dec 2015 12:26:24 -0500 Original-Received: by mail-wm0-x22b.google.com with SMTP id p187so119427038wmp.0; Tue, 22 Dec 2015 09:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=xhA5+Rg15rGo1YHB2JMuCPnT8J/l5qiAWUbfbBBiSiU=; b=EmBhz8ImgFfA7sF0Nie3dxXhp2lqetA+V5A4QQ425/HzD0SrWRe6Yf4s7MHV1kfIMO SlV3yKEfrY02VzY6qmv/j1RVoJp662tSraIxNhcu2MoumJHEpbeUYj8r66D66kbaA/gm yP+6N7jHIQxu7JTOQnWrio1q4h9q8eatb7BQlJnuT5zkfRJogE8UkxO2m5aI7tfq0CRT /fT1oz+CeeTK1Q8iF97iwp4T2cuVUXyFGMuiXXFSYs1m/WJ/jPSeorHz5nOFBBsbTUI7 JPTXVk5Ib+IiaYvQpROcO7sD/X5JMj4GziKTGgi40YeQ2GjfQzqXB3c/fmjtmX9LGLni x3RQ== X-Received: by 10.28.57.69 with SMTP id g66mr30308315wma.63.1450805183880; Tue, 22 Dec 2015 09:26:23 -0800 (PST) In-Reply-To: <83io3qqx7s.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22b 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:196678 Archived-At: --001a1148e7109fa43305277fe768 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Di., 22. Dez. 2015 um 17:11 Uhr: > > Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, > tzz@lifelogs.com, > > emacs-devel@gnu.org > > From: Daniel Colascione > > Date: Mon, 21 Dec 2015 22:14:38 -0800 > > > > And even if it were OK for (say) 'cat' to dump core due to > > > stack overflow in a typical environment (which it's not), Emacs is more > > > important than 'cat', because people use it as an interactive text > > > editor and do not want to lose their work. > > > > > >> we already crash if we overflow the stack while we're GCing. > > > > > > If so, that's a bug that should get fixed. It's not an excuse to > > > introduce similar bugs. > > > > > > Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs > > > should not crash. > > > > Ideally, we wouldn't have bugs. But we do, and when we hit them, we > > should crash reliably and deterministically if we can't recover > > reliably. > > I'm sorry, Daniel, but that kind of philosophy is a non-starter with > Emacs. Saving the user's work even in some cases is much better than > not saving it at all. And the current scheme is quite reliable, it > works in many scenarios, though not all of them. > > As for bugs that cause fatal errors, Emacs always tried to catch them > and at least auto-save. > IIUC this code (terminate_due_to_signal) already auto-saves without calling Lisp (or module) code, so this should be usable. We just need to make sure that module code is not run after a stack overflow. Would it be possible to chose this path if a module function is running? --001a1148e7109fa43305277fe768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 22. Dez. 2015 um 17:11=C2=A0Uhr:
> Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com,
>=C2=A0 emacs-d= evel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 21 Dec 2015 22:14:38 -0800
>
> And even if it were OK for (say) 'cat' to dump core due to
> > stack overflow in a typical environment (which it's not), Ema= cs is more
> > important than 'cat', because people use it as an interac= tive text
> > editor and do not want to lose their work.
> >
> >> we already crash if we overflow the stack while we're GCi= ng.
> >
> > If so, that's a bug that should get fixed. It's not an ex= cuse to
> > introduce similar bugs.
> >
> > Really, the idea that it's OK for Emacs to crash is a nonstar= ter. Emacs
> > should not crash.
>
> Ideally, we wouldn't have bugs. But we do, and when we hit them, w= e
> should crash reliably and deterministically if we can't recover > reliably.

I'm sorry, Daniel, but that kind of philosophy is a non-starter with Emacs.=C2=A0 Saving the user's work even in some cases is much better t= han
not saving it at all.=C2=A0 And the current scheme is quite reliable, it works in many scenarios, though not all of them.

As for bugs that cause fatal errors, Emacs always tried to catch them
and at least auto-save.=C2=A0

IIUC this= code (terminate_due_to_signal) already auto-saves without calling Lisp (or= module) code, so this should be usable. We just need to make sure that mod= ule code is not run after a stack overflow. Would it be possible to chose t= his path if a module function is running?=C2=A0
--001a1148e7109fa43305277fe768--