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 loading progress Date: Mon, 28 Sep 2015 15:12:28 +0000 Message-ID: References: <87vbgpk1po.fsf@lifelogs.com> <85mw20gmeo.fsf@stephe-leake.org> <878u97nyjn.fsf@lifelogs.com> <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134c69cc10dc40520d020cb X-Trace: ger.gmane.org 1443476343 18257 80.91.229.3 (28 Sep 2015 21:39:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 21:39:03 +0000 (UTC) Cc: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , Tom Tromey , Paul Eggert , Stephen Leake , Emacs development discussions To: Stefan Monnier , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 23:39:02 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 1Zgg8S-0007hx-QC for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 23:39:01 +0200 Original-Received: from localhost ([::1]:41040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg8S-0000Fm-1p for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 17:39:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zga6d-0000T9-Nn for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:12:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zga6Z-0004t7-J0 for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:12:43 -0400 Original-Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:37302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zga6Z-0004t2-9D for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:12:39 -0400 Original-Received: by wicfx3 with SMTP id fx3so105837999wic.0 for ; Mon, 28 Sep 2015 08:12:38 -0700 (PDT) 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=0e3qgOgtp3OUmCgkxQ8vWlxkLKbdPBsK8xzmSW9OFCA=; b=V1e0D7t84P9Ah/zjVahkwt1OI/RhANqwWRFDXtOFlXWgO8uhqyrjYXsfTq3AX2x9ER 544bhkgn3eWPqTGaGMScQRWtus5m/Q9RakTOKYDupXgWTpQO0PYkWeablPvdoN6t4bLn SWBe1cKP4kkIWGuPJbPxWWPwrTEhA47Z7Ewn5gmie7JavDQnRkxvJ9/ymYBmKErmAO+A WN5sM25fRiBiflZLWxmv7qs66S4nGLHyhomc8m0G2I4GnhVpApwKhSzSghqIUL1odUeV WJJ5NuJdwZK3xprH33RVwd0edjY2liScRnWYp+FikkMjZY3Aa05CZsl4V7oxb45tdBH0 4Vng== X-Received: by 10.180.216.36 with SMTP id on4mr19674720wic.65.1443453158360; Mon, 28 Sep 2015 08:12:38 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::234 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:190441 Archived-At: --001a1134c69cc10dc40520d020cb Content-Type: text/plain; charset=UTF-8 Stefan Monnier schrieb am Mo., 14. Sep. 2015 um 03:58 Uhr: > >>> It's not possible to skip frames in module code using longjmp, so > >> Why not? > > Because most C code isn't expecting to be unwound. > > Forcing non-local flow control on module code is completely > > unacceptable. Emacs needs to return with an error indication set. > > Hmm... I'm still not sure what's the issue. > > AFAICT, the only odd case I can think of is the following: > > 1- Emacs calls some module code via the new API. > 2- This code (which is Emacs-specific) will know about Fthrow. > Even if it knows about non-local jumps, in many cases it can't do anything about them except wrapping them. For example, longjmp is illegal in most C++ programs (and probably in most other languages as well). > 3- It may call some non-Emacs-specific code from some other library. 4- This non-Emacs-specific code calls back to some Emacs-specific > function. > Step 3 and 4 can be left out. The issue only requires that the plugin contains some code that is not suited for longjmp; e.g., all C++ code, no matter whether written specifically for Emacs or not. > 5- This Emacs-specific function calls Fthrow/Fsignal. > > Where the problem only shows if/when we reach point 5. > > This problem can be handled between 4 and 5 by using an appropriate > internal_condition_case. > Partially yes. internal_condition_case with a Qt handler can indeed catch all signals, but this invocation is only possible from Emacs C code (using internal_condition_case), and the fact that signal and throw use longjmp is an implementation detail anyway, so the catch-all code needs to be inside the module code. --001a1134c69cc10dc40520d020cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Stefan= Monnier <monnier@iro.umontr= eal.ca> schrieb am Mo., 14. Sep. 2015 um 03:58=C2=A0Uhr:
>>> It's not possible to skip fra= mes in module code using longjmp, so
>> Why not?
> Because most C code isn't expecting to be unwound.
> Forcing non-local flow control on module code is completely
> unacceptable.=C2=A0 Emacs needs to return with an error indication set= .

Hmm... I'm still not sure what's the issue.

AFAICT, the only odd case I can think of is the following:

=C2=A0 =C2=A01- Emacs calls some module code via the new API.
=C2=A0 =C2=A02- This code (which is Emacs-specific) will know about Fthrow.=

Even if it knows about non-local jumps= , in many cases it can't do anything about them except wrapping them. F= or example, longjmp is illegal in most C++ programs (and probably in most o= ther languages as well).
=C2=A0
=C2=A0 =C2=A03- It may call some non-Emacs-specific code from some other li= brary.=C2=A0
=C2=A0 =C2=A04- This non-Emacs-specific code calls back to some Emacs-speci= fic function.

Step 3 and 4 can be left = out. The issue only requires that the plugin contains some code that is not= suited for longjmp; e.g., all C++ code, no matter whether written specific= ally for Emacs or not.
=C2=A0
=C2=A0 =C2=A05- This Emacs-specific function calls Fthrow/Fsignal.

Where the problem only shows if/when we reach point 5.

This problem can be handled between 4 and 5 by using an appropriate
internal_condition_case.

Partially yes. internal_condition_case wit= h a Qt handler can indeed catch all signals, but this invocation is only po= ssible from Emacs C code (using internal_condition_case), and the fact that= signal and throw use longjmp is an implementation detail anyway, so the ca= tch-all code needs to be inside the module code.
--001a1134c69cc10dc40520d020cb--