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: Mon, 29 Feb 2016 22:48:08 +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=089e0102ee20dfdddd052cf07123 X-Trace: ger.gmane.org 1456786119 30939 80.91.229.3 (29 Feb 2016 22:48:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 22:48:39 +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 Mon Feb 29 23:48:32 2016 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 1aaWcA-0007Vg-FZ for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 23:48:30 +0100 Original-Received: from localhost ([::1]:39487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaWc9-0006fc-EP for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 17:48:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaWc0-0006V6-Rq for emacs-devel@gnu.org; Mon, 29 Feb 2016 17:48:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaWbz-0005f9-Fu for emacs-devel@gnu.org; Mon, 29 Feb 2016 17:48:20 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:37069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaWby-0005ei-VI; Mon, 29 Feb 2016 17:48:19 -0500 Original-Received: by mail-wm0-x231.google.com with SMTP id p65so9969064wmp.0; Mon, 29 Feb 2016 14:48:18 -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; bh=/pAY3iyqyen/5ZV6tQ+/aVxfJjanS3BfMv6rBn2Q5vA=; b=ZsMj6FAjdFrAmrCiabRbByuwmJbvTOdaDcA+cTJwg4BN8IBpLOtHMRTjkswmzCnE4n nw1aRVa/65vaXEpfmpzEMEVvQniBK8OeFscRB6LUhLAWwFZ2yTrYSb80Wk9g7UxerY9X 05SetAH9se2HAstJ/Xz/zvvElOpOfaALgRU0QP4N7YosAurD8VcP6UoucKVfa528zAEV lCYFEWKdBAWCiKvkCoeEaFNqGk82lYnLzsZtpfQWPWTFRt5DOmpzYmZnPnTkGSoJHXr8 tGX/XBK4xrKAQZxP1mYtiyYKalQLCNmQ5rCQOVRsLQydC3kv6nwoElb8sgTsvmPPzYZj Gn1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/pAY3iyqyen/5ZV6tQ+/aVxfJjanS3BfMv6rBn2Q5vA=; b=lCszCxKyRhhZgNdWoQX1TaDPJKlUBqJBRZ3M6qV6O6ooCjLkn56Ali6aVVap6Ted/j isTc2J8WnPX76BQEzM+9YzAiHVoOHxWcZsiQS7BqFJEQocCbrYgmQGfDXRAFU4NKeDJc ZjKzGl6d/zICx5XEQ0mN6tU5gvXCNGFQajHtlgYrV2/WFloHmmMKkGaA7YOfz9/rpIEo XhISx+ZX26G4gIOJ/s0RJhBeB6AuTpu8VTbkkbSqMM1oAnKo2BZ1y0qKV8iJKaR0fKWQ q2nEw/Da1KabBPBO3MquBr4ksqyGqqUQ9DBphH5HLYld2U7yzMgn+sbzu8B5m/mRjwcu +mlg== X-Gm-Message-State: AD7BkJJFEbmrsgkhdNi3wPJKlQJuygRcoGYLzjlPcq3agjGdsS+iYfxoS0/P6H/MNBtL/B4pEfiBjDLZ1keB7Q== X-Received: by 10.194.87.161 with SMTP id az1mr17015004wjb.163.1456786097820; Mon, 29 Feb 2016 14:48:17 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:200830 Archived-At: --089e0102ee20dfdddd052cf07123 Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am Sa., 19. Dez. 2015 um 22:03 Uhr: > Philipp Stephani schrieb am Sa., 28. Nov. 2015 um > 11:58 Uhr: > >> Philipp Stephani schrieb am Fr., 27. Nov. 2015 >> um 20:19 Uhr: >> >>> 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. >>> >> >> For now I've attached a patch to replace the initial setup of most >> environment functions with a single macro. >> > > Here's another patch that replaces some of the custom error handling with > signals. The signals will be immediately caught by the prologue, but some > complexity and duplication is removed. > Could this patch please be reviewed and/or applied? Thanks. --089e0102ee20dfdddd052cf07123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Sa., 19. Dez. 2015 um 22:03=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> schrieb am Sa., 28. Nov. 2015= um 11:58=C2=A0Uhr:
Eli Zaretskii <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 not we should probabl= y be conservative and =C2=A0assume that everything signals. If we figure ou= t that this introduces an unacceptably high overhead in some situations we = can reconsider later.
I would propose three exceptions: free_glob= al_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 deall= ocation functions such as free(3). is_not_nil and eq seem so fundamental th= at I cannot imagine a situation where they could ever fail. Documenting tha= t these three cannot fail would free module authors from the need to check = for errors after calling these functions.

Fo= r now I've attached a patch to replace the initial setup of most enviro= nment functions with a single macro.=C2=A0

Here's another patch that replaces some of the custom error handling= with signals. The signals will be immediately caught by the prologue, but = some complexity and duplication is removed.=C2=A0

Could this patch please be reviewed and/or applied= ? Thanks.=C2=A0
--089e0102ee20dfdddd052cf07123--