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: Wed, 23 Dec 2015 16:20:45 +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> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114432fe44157e0527931b00 X-Trace: ger.gmane.org 1450887671 6655 80.91.229.3 (23 Dec 2015 16:21:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 16:21:11 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 23 17:21:10 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 1aBmA1-0007jS-9c for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 17:21:09 +0100 Original-Received: from localhost ([::1]:56783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmA0-0004nV-Fl for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 11:21:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBm9v-0004nO-N9 for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:21:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBm9u-0000gl-10 for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:21:03 -0500 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:36551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBm9n-0000cZ-Dc; Wed, 23 Dec 2015 11:20:55 -0500 Original-Received: by mail-wm0-x22f.google.com with SMTP id p187so152346700wmp.1; Wed, 23 Dec 2015 08:20:55 -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=CYnm352Kn+aTxDS3LgJTNjOZd2w21JGvVmNvcwUtpZI=; b=okcQasYylzgwqTntikEzQI2T/jV1m1EDjtfqbsDU8/R/EpxT87yPjXDpdEtcaRPwlh 9S4pBvbK3E6f68idBwBBBBAAiqAygCvhbJRLY86WRRAy0hzZsY/qGqruPdMQai6O+gHX rDyUWojQx/LTTPsEJjW3uQNxNlq2eEXsNkptkduplbppMFlmc+tRPRVioHnkEpLmWnyG MjeG7gNebqcy2AQLkXFN9Rs5zVzEgZ174xFnbzcpB2HsCJo/uLGvQMYaDCljxFnm/jGd 6r0xxdjj5aYCJsSe6XzLg5o2DUVVRiG2p06CiJosTCofFfuCVnGjFvSk4yR6NuHo/UpW pNQQ== X-Received: by 10.28.137.67 with SMTP id l64mr34281922wmd.33.1450887654673; Wed, 23 Dec 2015 08:20:54 -0800 (PST) In-Reply-To: <83oadhp2mj.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::22f 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:196713 Archived-At: --001a114432fe44157e0527931b00 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Mi., 23. Dez. 2015 um 17:10 Uhr: > > Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, > dancol@dancol.org, > > tzz@lifelogs.com, emacs-devel@gnu.org > > From: Paul Eggert > > Date: Tue, 22 Dec 2015 15:28:03 -0800 > > > > Is that practical? One problem that I, as a module developer would > > face, is to estimate the amount of stack I'd need for unwinding. > > Where do I begin? > > > > We could merely require that any module needing recursion must call a > new stack-size-checking function at each level of recursion, in order to > detect stack overflow. > > That's performance penalty. I don't think we should incur that, on > behalf of a problem that really should "never" happen. > It's also impossible. Modules will be written in arbitrary languages and make use of arbitrary libraries, some of which might not even know about Emacs's existence. We cannot impose any constraints on module code. > > > Also, any module with an unbounded amount of computation should call the > equivalent of QUIT every now and then. If the module API doesn't let (or > ideally, require) modules to do that now, it should. Otherwise it's an > Emacs freeze waiting to happen. > > I agree, but I think it's unrelated to stack overflow. (Though I > think we will need to have a module-specific version of QUIT, as long > as we keep the constraint of not directly longjmping from module > code.) > There's no harm in providing such a functionality (but of course we can't enforce its use). Alternatively modules can run computations in background threads and update Emacs state in timer functions. > > > > Hitting stack overflow when some module runs is even rarer. > > Why is it a disaster to fail to invoke the unwinders in those cases? > > > > Often I expect it wouldn't be a disaster; it'd just be a memory leak. I > suppose there could be some modules where it would be a disaster. But > perhaps we can just ask people to not write such modules, by making it a > part of the Emacs API that unwinders might not be invoked. > > I think if we adopt the view that the user should save and exit ASAP > following recovery from stack overflow (similar to what we expect when > we run out of memory), the probability of a "disaster" in this > scenario becomes much lower, perhaps negligible. > The disaster is that longjmps cause undefined behavior in C++ if destructors would be skipped (and I don't even want to imagine what would happen to higher-level languages such as Java or Haskell). Even if we assume "benign UB" (which is dangerous because UB tends to become more malign as compilers evolve), it will cause internal state to become inconsistent, which is truly disastrous. Resuming operation in such a situation is a non-starter. > All in all, I think the current recovery is "good enough", and > investing significant efforts into making it slightly better will > waste resources that are better applied to more important problems. > > handle_sigsegv already has several cases where the longjmp is skipped: when in a GC, when the signal is received from the wrong thread, and when it's not guaranteed to be a SO. In those cases Emacs aborts (still autosaving). Why can't we do the same if SO is detected while a module function is active? --001a114432fe44157e0527931b00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mi., 23. Dez. 2015 um 17:10=C2=A0Uhr:
> Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org,
>=C2=A0 tzz@lifelo= gs.com, emacs-= devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 22 Dec 2015 15:28:03 -0800
>
>=C2=A0 =C2=A0 =C2=A0Is that practical?=C2=A0 One problem that I, as a m= odule developer would
>=C2=A0 =C2=A0 =C2=A0face, is to estimate the amount of stack I'd ne= ed for unwinding.
>=C2=A0 =C2=A0 =C2=A0Where do I begin?
>
> We could merely require that any module needing recursion must call a = new stack-size-checking function at each level of recursion, in order to de= tect stack overflow.

That's performance penalty.=C2=A0 I don't think we should incur tha= t, on
behalf of a problem that really should "never" happen.

It's also impossible. Modules will be written= in arbitrary languages and make use of arbitrary libraries, some of which = might not even know about Emacs's existence. We cannot impose any const= raints on module code.
=C2=A0

> Also, any module with an unbounded amount of computation should call t= he equivalent of QUIT every now and then. If the module API doesn't let= (or ideally, require) modules to do that now, it should. Otherwise it'= s an Emacs freeze waiting to happen.

I agree, but I think it's unrelated to stack overflow.=C2=A0 (Though I<= br> think we will need to have a module-specific version of QUIT, as long
as we keep the constraint of not directly longjmping from module
code.)

There's no harm in providing= such a functionality (but of course we can't enforce its use). Alterna= tively modules can run computations in background threads and update Emacs = state in timer functions.
=C2=A0


>=C2=A0 =C2=A0 =C2=A0Hitting stack overflow when some module runs is eve= n rarer.
>=C2=A0 =C2=A0 =C2=A0Why is it a disaster to fail to invoke the unwinder= s in those cases?
>
> Often I expect it wouldn't be a disaster; it'd just be a memor= y leak. I suppose there could be some modules where it would be a disaster.= But perhaps we can just ask people to not write such modules, by making it= a part of the Emacs API that unwinders might not be invoked.

I think if we adopt the view that the user should save and exit ASAP
following recovery from stack overflow (similar to what we expect when
we run out of memory), the probability of a "disaster" in this scenario becomes much lower, perhaps negligible.

<= /div>
The disaster is that longjmps cause undefined behavior in C++ if = destructors would be skipped (and I don't even want to imagine what wou= ld happen to higher-level languages such as Java or Haskell). Even if we as= sume "benign UB" (which is dangerous because UB tends to become m= ore malign as compilers evolve), it will cause internal state to become inc= onsistent, which is truly disastrous. Resuming operation in such a situatio= n is a non-starter.


All in all, I think the current recovery is "good enough", and investing significant efforts into making it slightly better will
waste resources that are better applied to more important problems.


handle_sigsegv already has several cas= es where the longjmp is skipped: when in a GC, when the signal is received = from the wrong thread, and when it's not guaranteed to be a SO. In thos= e cases Emacs aborts (still autosaving). Why can't we do the same if SO= is detected while a module function is active?=C2=A0
--001a114432fe44157e0527931b00--