From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Module support: No environment in pointer release function Date: Sun, 26 Feb 2017 16:23:47 +0000 Message-ID: References: <87poismx76.fsf@hochschule-trier.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c124d96ceb75705497163f3 X-Trace: blaine.gmane.org 1488126282 1702 195.159.176.226 (26 Feb 2017 16:24:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 16:24:42 +0000 (UTC) Cc: emacs-devel To: =?UTF-8?Q?Elias_M=C3=A5rtenson?= , Andreas Politz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 26 17:24:38 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ci1cj-0008G3-5I for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 17:24:37 +0100 Original-Received: from localhost ([::1]:47418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci1co-0003bz-My for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 11:24:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci1c8-0003br-NV for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:24:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ci1c7-0005fm-8m for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:24:00 -0500 Original-Received: from mail-pg0-x234.google.com ([2607:f8b0:400e:c05::234]:36387) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ci1c7-0005fD-09 for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:23:59 -0500 Original-Received: by mail-pg0-x234.google.com with SMTP id s67so32919922pgb.3 for ; Sun, 26 Feb 2017 08:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g0dELW/Se/N9ZVeYebZbqIkwd5G4ql7jOXcoQi8vuZ4=; b=hZjFZC7oSJHQI0iVabxtrAzOqsFYzLOAr6SNkij3fNOP4bYczzq7PXopYSpyYZuM6G kONnqTY/opMt7RQ68iasX+SEngWtuJP8kDBpLiepKG6NrtdQ5IKA1zNBn4+Zu7yQdDVg Y6TSWnc8prpgkd3pe9u3JGN8bso4T5MSxJ4yaVzR6acLkySfGPQDaQ0+sp4F6Vt58RFB g/pW0gCmuKp2kHi0U0aImtR9IqskocgH2DkY3rH0n/a5TwRFBFUuAUbBGYQe3K7ezseT lGTMvoJAdji94SBqz72bS+TvRrQ/np/M4VNRUileWQly/WbTmOisRZM5BdmGTBC4XL1K dMOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g0dELW/Se/N9ZVeYebZbqIkwd5G4ql7jOXcoQi8vuZ4=; b=H/r7NCDFIZsGpikoIC+t/LwLS7+2mxD0CKdFSTHusUUT6KqjZ5lv3AE+AIPANM4qQ9 Ty832AKKEdjCBdgYUfC3r9wEEniSqeQLQkGMTjtAPQOOOrRgLgQxgKqTtCGDBjDd+dhW x43UvA4k/nm1LUeFvqL8R8LlhUcRAfL4gzSfL0PSdt6g17erw+yipU/sqAru4qc2tYdJ DfSuJvthisM7IRjMkaag826XhRZEp/W1hNRyl9aqkTqOSSH5NHh8SZPPYRbfxFM8X2e7 fp5ALeVh0J9YSkHVMRE8LmBPik6JmZ9KUYuLLVebUFm8tYZa3VCoSJa9YDNrWQ5DCWyC J3ww== X-Gm-Message-State: AMke39nha1rB7cZ7xczOKXjgVRWO3uPJXjUJ79rhEk9XQXz+fDE8X8O7qzvOeb0ywXUBnnnFJ1HzaTluH90ZVw== X-Received: by 10.84.132.33 with SMTP id 30mr18329601ple.44.1488126238174; Sun, 26 Feb 2017 08:23:58 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c05::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212612 Archived-At: --94eb2c124d96ceb75705497163f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Elias M=C3=A5rtenson schrieb am Fr., 10. Feb. 2017 um 06:21 Uhr: > On 9 February 2017 at 01:03, Andreas Politz > wrote: > > Elias M=C3=A5rtenson writes: > > > [...] In it, I have to use the make_user_ptr() function in a few > > places. When creating a user_ptr, the function accepts a pointer to a > > function which will be called when the object is GC'ed. > > How do you even know its your pointer and not someone elses ? > > > Because it was me who created the pointer. In the specific case, when I > call the GSSAPI function gss_import_name(), this function returns a point= er > to an opaque object which needs to be released using the function > gss_release_name(). > > I package up this pointer using env->make_user_pointer() which accept a > function that is responsible for freeing the pointer when it's GC'ed. > > The issue is that gss_import_name() can return an error. Of course, I've > never actually seen it return an error, and I doubt that it ever will in > practice. But I'm struggling with the correct way to handle an error. At > the very least, I want to know it happened since that would reveal a bug = in > my code. > > Right now I simply call abort() if there is an error. Excessive, I know, > but at least I know when there is a problem and the stack trace gives me > all the answers I need. > > I'm not sure I should keep the abort() in the final version though. > Probably not. You should either log (on stderr) and ignore the error, or not call gss_release_name (or any other function that can fail) in a finalizer. Just like they Java counterpart, finalizers can't fail. There's also no guarantee that they ever be called, or when they are called, so you shouldn't use them to implement cleanup that has to be deterministic or can fail. --94eb2c124d96ceb75705497163f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 February 2017= at 01:03, Andreas Politz <politza@hochschule-trier.de> wrote:
Elias M=C3=A5rtenson <lokedhs= @gmail.com> writes:

> [...] In it, I have to use the make_user_ptr() function in a few
> places. When creating a user_ptr, the functi= on accepts a pointer to a
> function which will be called when the object is GC'ed.

How do you even know its your pointer and not someone elses ?

Because it= was me who created the pointer. In the specific case, when I call the GSSA= PI function gss_import_name(), this function returns a pointer to an opaque= object which needs to be released using the function gss_release_name().

I package up this pointer using env->make_user_pointer() which = accept a function that is responsible for freeing the pointer when it's= GC'ed.

The issue is that gss_import_name() can return an err= or. Of course, I've never actually seen it return an error, and I doubt= that it ever will in practice. But I'm struggling with the correct way= to handle an error. At the very least, I want to know it happened since th= at would reveal a bug in my code.

Right now I simply call abort= () if there is an error. Excessive, I know, but at least I know when there = is a problem and the stack trace gives me all the answers I need.

I'm not sure I should keep the abort() in the final version though.

Probably not. You sho= uld either log (on stderr) and ignore the error, or not call gss_release_na= me (or any other function that can fail) in a finalizer.
Just lik= e they Java counterpart, finalizers can't fail. There's also no gua= rantee that they ever be called, or when they are called, so you shouldn= 9;t use them to implement cleanup that has to be deterministic or can fail.=
--94eb2c124d96ceb75705497163f3--