From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 28 Sep 2015 15:20:10 -0400 Message-ID: References: <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: text/plain X-Trace: ger.gmane.org 1443488629 29819 80.91.229.3 (29 Sep 2015 01:03:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 01:03:49 +0000 (UTC) Cc: Paul Eggert , Tom Tromey , Emacs development discussions , =?windows-1252?Q?Aur=E9lien?= Aptel , Daniel Colascione , Stephen Leake To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 29 03:03: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 1ZgjKY-0008Qq-LP for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2015 03:03:42 +0200 Original-Received: from localhost ([::1]:43408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgjKX-0006xj-VF for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 21:03:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgdzC-0005pR-H6 for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:21:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgdz7-0006sR-P5 for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:21:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:35454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgdz7-0006rb-Lm for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:21:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CVDQA731xV/wihxEVcgxCEAsEVh0sEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAgEfizqFBQeELQWzP4FFI4QUIoJ4AQEB X-IPAS-Result: A0CVDQA731xV/wihxEVcgxCEAsEVh0sEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAgEfizqFBQeELQWzP4FFI4QUIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="166108297" Original-Received: from 69-196-161-8.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.8]) by ironport2-out.teksavvy.com with ESMTP; 28 Sep 2015 15:20:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 3A9AD61769; Mon, 28 Sep 2015 15:20:10 -0400 (EDT) In-Reply-To: (Philipp Stephani's message of "Mon, 28 Sep 2015 15:12:28 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:190455 Archived-At: >> 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. There's nothing else none can ever do about them other than wrapping them. So the fact that they can only wrap them is not a downside of some alternative. > For example, longjmp is illegal in most C++ programs (and probably in > most other languages as well). Most Emacs modules will be written in C, methinks. For those written in other languages, since the API is expressed in C, they'll have to accommodate the interaction with this C API, yes. If they want to add a whole layer that wraps every function call in an internal_condition_case, that's fine by me. > 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. That's a problem for the C++ code, not for Emacs's C-level module API. > 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), Clearly, we'll want to export it to the modules as well. Stefan