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: Fri, 27 Nov 2015 19:19:44 +0000 Message-ID: References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <83io4nuc68.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114450c884b8ff05258a9355 X-Trace: ger.gmane.org 1448652005 17215 80.91.229.3 (27 Nov 2015 19:20:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 19:20:05 +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 Fri Nov 27 20:20: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 1a2OYp-0007OG-DA for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 20:19:59 +0100 Original-Received: from localhost ([::1]:58237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2OYs-0001U6-93 for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 14:20:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2OYo-0001Tq-0z for emacs-devel@gnu.org; Fri, 27 Nov 2015 14:19:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2OYn-00068x-3k for emacs-devel@gnu.org; Fri, 27 Nov 2015 14:19:58 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:34241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2OYl-00068d-0E; Fri, 27 Nov 2015 14:19:55 -0500 Original-Received: by wmvv187 with SMTP id v187so82317969wmv.1; Fri, 27 Nov 2015 11:19:54 -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=g70ru1mKGHMw75lQ0l82EfCapuG0DhIvDQQvXK3JKAU=; b=qxGQ2p4Y9eNvhBpVu0eBTBYAoP/CIuEtduetZmYaF0tTyBLEQTePzlHtWScyKhAHXM DFW0l6XTG0on+IvOz+1YJ0DkRsH/UaPIx28taQ1Ldho64JkCnG75+DGvmF1tyJXDzN/K r2uXfc2fZo10BXgNK/OPG/bqudKhvX/S4qEe9tGKRHbVIjYviSDuo7hgNO/+7tBQfKF0 OojSFtpYoivN1BdrElUypYuZmzKR6itzI7c66RZygrW9aie7F8GEkLBjVRlXnuxC3Kmb sa9wjwwxv0OwZO35i1e5OdAkO9PLxpSFbtxtvQlE2lf18fSa6DE2b3iAx6yV7Eio7unH 97Bw== X-Received: by 10.28.7.8 with SMTP id 8mr11921235wmh.45.1448651994215; Fri, 27 Nov 2015 11:19:54 -0800 (PST) In-Reply-To: <83io4nuc68.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::231 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:195410 Archived-At: --001a114450c884b8ff05258a9355 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Fr., 27. Nov. 2015 um 08:36 Uhr: > > Cc: emacs-devel@gnu.org > > From: Paul Eggert > > Date: Thu, 26 Nov 2015 13:29:49 -0800 > > > > Eli Zaretskii wrote: > > > it would be a maintenance burden to have to > > > analyze upon each such change whether emacs-module.c needs some > > > augmentation. > > > > While that's true in general, I think some exceptions are OK. E.g., > it's OK if > > emacs-module.c assumes that ASIZE is a simple access function or macro > that > > doesn't throw signals. If we actually changed ASIZE to throw signals, > there's a > > boatload of other code we'd need to change as well, and changing > emacs-module.c > > wouldn't add much more to the maintenance burden. > > So what are the rules here, exactly? I'd like to write them down in > the commentary to emacs-module.c, so that any future changes there > will have lower probability of breaking things. > > E.g., can make_number signal an error? What about make_float or > make_string? And what about accessors like XFLOAT_DATA or AREF? > > Are there any established rules? If not we should probably be conservative and assume that everything signals. If we figure out that this introduces an unacceptably high overhead in some situations we can reconsider later. I would propose three exceptions: free_global_ref, is_not_nil, eq. free_global_ref cannot fail in Daniel's design, and implementing it that way would be consistent with other resource deallocation functions such as free(3). is_not_nil and eq seem so fundamental that I cannot imagine a situation where they could ever fail. Documenting that these three cannot fail would free module authors from the need to check for errors after calling these functions. --001a114450c884b8ff05258a9355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Fr., 27. Nov. 2015 um 08:36=C2=A0Uhr:
> Cc: emacs= -devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 26 Nov 2015 13:29:49 -0800
>
> Eli Zaretskii wrote:
> > it would be a maintenance burden to have to
> >=C2=A0 =C2=A0 =C2=A0 analyze upon each such change whether emacs-m= odule.c needs some
> >=C2=A0 =C2=A0 =C2=A0 augmentation.
>
> While that's true in general, I think some exceptions are OK.=C2= =A0 E.g., it's OK if
> emacs-module.c assumes that ASIZE is a simple access function or macro= that
> doesn't throw signals.=C2=A0 If we actually changed ASIZE to throw= signals, there's a
> boatload of other code we'd need to change as well, and changing e= macs-module.c
> wouldn't add much more to the maintenance burden.

So what are the rules here, exactly?=C2=A0 I'd like to write them down = in
the commentary to emacs-module.c, so that any future changes there
will have lower probability of breaking things.

E.g., can make_number signal an error?=C2=A0 What about make_float or
make_string?=C2=A0 And what about accessors like XFLOAT_DATA or AREF?


Are there any established rules? If no= t we should probably be conservative and =C2=A0assume that everything signa= ls. If we figure out that this introduces an unacceptably high overhead in = some situations we can reconsider later.
I would propose three ex= ceptions: free_global_ref, is_not_nil, eq. free_global_ref cannot fail in D= aniel's design, and implementing it that way would be consistent with o= ther resource deallocation functions such as free(3). is_not_nil and eq see= m so fundamental that I cannot imagine a situation where they could ever fa= il. Documenting that these three cannot fail would free module authors from= the need to check for errors after calling these functions.
--001a114450c884b8ff05258a9355--