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: Sun, 22 Nov 2015 09:03:39 +0000 Message-ID: References: <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <837fld6lps.fsf@gnu.org> <83610w5o97.fsf@gnu.org> <564FACF5.2080601@cs.ucla.edu> <564FBAA7.5030306@cs.ucla.edu> <5650F9CD.9030707@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0102def408e01e05251d63e3 X-Trace: ger.gmane.org 1448183039 29689 80.91.229.3 (22 Nov 2015 09:03:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 09:03:59 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 10:03:58 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 1a0QYv-0005Tf-7V for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 10:03:57 +0100 Original-Received: from localhost ([::1]:55252 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QYu-00074T-Tc for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 04:03:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QYr-00073c-KR for emacs-devel@gnu.org; Sun, 22 Nov 2015 04:03:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0QYq-0003H2-FI for emacs-devel@gnu.org; Sun, 22 Nov 2015 04:03:53 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:38299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0QYo-0003F8-6S; Sun, 22 Nov 2015 04:03:50 -0500 Original-Received: by wmec201 with SMTP id c201so69729751wme.1; Sun, 22 Nov 2015 01:03:49 -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=IYyQ/G9yq+lnNCNKrBMdFkWL2YykXz3NDv31zqcs8xE=; b=WGFJz0aT20xhkgWSmRrSb6FuvU2IWS1k4kztO46C74YBahdHnGeAubYYX8aa5TEZ17 uJyW5IYg7dZDLvjhLzfarNvGBb0bIbw9QBAIm0VyNI4DsXbe/cYqxxyOvHuJQ3J27KBs 64CvIiBO3ZeCIF9q0tj217TZeEeRzmoyfCcluPMTBCo2wrTrHak1zeJIv8zc7iytYpw1 XU0U6sRloks0n9JUUmng/sMN5LouEZGmSDUDSvy7AZz/eQF1jMy/3PrFgI3EupJNMKGh dfvzx+S+3I0RwYQQqgYhFi3+Qw1SHSM+hLh9gC1YOtDX38Lb8bXvmn3NmhTr2dU4WoGo S8+A== X-Received: by 10.194.87.39 with SMTP id u7mr24485353wjz.11.1448183029356; Sun, 22 Nov 2015 01:03:49 -0800 (PST) In-Reply-To: <5650F9CD.9030707@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22c 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:194992 Archived-At: --089e0102def408e01e05251d63e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul Eggert schrieb am So., 22. Nov. 2015 um 00:10 Uhr= : > Philipp Stephani wrote: > >> Many modules will have needs similar to Emacs itself in > >> >that > >> >respect, and it would be better if they didn't have to reinvent this > >> >so-common > >> >wheel. > >> > > > But what should the interface be? There are only three possibilities in > C: > > return a sentinel value, crash, longjmp. > > There's a fourth possibility: do what Emacs does. Emacs defines its own > throw-catch mechanism built atop C. C modules that need to cleanup when > unwound > can do so by registering via the equivalent of record_unwind_protect, and > Emacs > won't longjmp through them without cleaning up. This already works for > xmalloc > memory-exhaustion failures, and modules can just use the already-existing > mechanism. > We have already discussed longjmp at length in this thread, and Daniel, Aur=C3=A9lien and I are all strongly against it. Using longjmp makes it effectively impossible to write modules in any language but C, and even C code has to be very careful (e.g. it can't use __attribute__((cleanup))). longjmp is only possible within a monolithic system that is able to make closed-world assumptions such as the Emacs binary itself, it is impossible in generic and portable library code. We have worked hard to remove the possibility of longjmp leaking into module code, and I won't put that possibility back in. --089e0102def408e01e05251d63e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am So., 22. Nov. 2015 um 00:10=C2=A0Uhr:
Philipp Stephani wrote:
>> Many modules will have needs similar to Emacs itself in
>> >that
>> >respect, and it would be better if they didn't have to rei= nvent this
>> >so-common
>> >wheel.
>> >
> But what should the interface be? There are only three possibilities i= n C:
> return a sentinel value, crash, longjmp.

There's a fourth possibility: do what Emacs does. Emacs defines its own=
throw-catch mechanism built atop C. C modules that need to cleanup when unw= ound
can do so by registering via the equivalent of record_unwind_protect, and E= macs
won't longjmp through them without cleaning up.=C2=A0 This already work= s for xmalloc
memory-exhaustion failures, and modules can just use the already-existing m= echanism.

We have already discussed lon= gjmp at length in this thread, and Daniel, Aur=C3=A9lien and I are all stro= ngly against it. Using longjmp makes it effectively impossible to write mod= ules in any language but C, and even C code has to be very careful (e.g. it= can't use __attribute__((cleanup))). longjmp is only possible within a= monolithic system that is able to make closed-world assumptions such as th= e Emacs binary itself, it is impossible in generic and portable library cod= e. We have worked hard to remove the possibility of longjmp leaking into mo= dule code, and I won't put that possibility back in.=C2=A0
<= /div> --089e0102def408e01e05251d63e3--