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: GNUS Kerberos support, native GSSAPI? Date: Sun, 23 Apr 2017 17:31:28 +0000 Message-ID: References: <87a89vmvd5.fsf@fastmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143d6b807f440054dd8dd5a X-Trace: blaine.gmane.org 1492968743 18013 195.159.176.226 (23 Apr 2017 17:32:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Apr 2017 17:32:23 +0000 (UTC) Cc: Joakim Jalap , emacs-devel To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , =?UTF-8?Q?Elias_M=C3=A5rtenson?= , Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 23 19:32:19 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 1d2LMt-0004Tv-RQ for ged-emacs-devel@m.gmane.org; Sun, 23 Apr 2017 19:32:16 +0200 Original-Received: from localhost ([::1]:40039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2LMz-0004W4-KQ for ged-emacs-devel@m.gmane.org; Sun, 23 Apr 2017 13:32:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2LMM-0004Vm-Bm for emacs-devel@gnu.org; Sun, 23 Apr 2017 13:31:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2LML-0007Xw-DV for emacs-devel@gnu.org; Sun, 23 Apr 2017 13:31:42 -0400 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:36220) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d2LML-0007XA-5R for emacs-devel@gnu.org; Sun, 23 Apr 2017 13:31:41 -0400 Original-Received: by mail-wm0-x22b.google.com with SMTP id u65so7695009wmu.1 for ; Sun, 23 Apr 2017 10:31:41 -0700 (PDT) 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=sQMbwo4eXzUco2l2kVywQnmjnW8kaHKckAAEwtVmem8=; b=n7ra58cuphPDEkTzmeyOTkrhbCz1vYHkl3CkD5sqxAEtqlxQeeoNewTPbRb/djvYVg 63rkcKbXOsuV9nbriHQp9IhFvZYTqpPgJBlBay3tSGzHctGA+bLHIbAfU4/OFTZTplFu zMScAspJ6S+erZX2jlqvgAoL0H6QTrSSPjoF9MakU+dkpdCzS0DW3LUTI2qcqE47SyLy dhf66n/0VFPD117m0xooswm/NLRW7tKDJsNpomDy+xm/zrlu5LEApzT7hibgwfDTAGg+ t8dooZ7iGd6v7PzXe5yR/R8e4wMgwYF2ccN4/5vU0+j8PI+qz5Y/azDQKTIaxcJ5UQ/k VMLQ== 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=sQMbwo4eXzUco2l2kVywQnmjnW8kaHKckAAEwtVmem8=; b=VeTA0FSclCMKVtrvv0QjLTrbpfwDYFEVEtXNWycuvuYX4tgFyuy3Xoby6vYmpyiqHv HPWZqIW6ReGz3WahLTrLHMOK5kKxJbpvxtRDrBUIIehPtZigaofooV/d1q9v43soAsMV UjEEQWPOMMuIbfqDPiPJKFzrbndj+JF/b83/FFaG8XIqU06iZsGHQUF8Zr8hpZV+N8K0 HQOqJO7jbWbOFMXauX46cp3bqp0K8Xxu1tTijtR7EIJzF9IgM8mwfQH4JgIH8oGOomQG 7PZiKUKFzzY+xZWtFyG6bsmLUhc6QVVHf89I85vXAy4E2vGobxvybsdS5BtJZD3Woaap GniQ== X-Gm-Message-State: AN3rC/63ZupkmIObTthQoiSQgXLnvVHTni5kj/fEii33EaJs72dhb+US JirFiBaiOihJBdiFl7RS+TUyD2dp0w== X-Received: by 10.28.55.9 with SMTP id e9mr6593514wma.44.1492968700111; Sun, 23 Apr 2017 10:31:40 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22b 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:214250 Archived-At: --001a1143d6b807f440054dd8dd5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am Fr., 10. Fe= b. 2017 um 19:21 Uhr: > > > I tried putting all the interned symbols in a struct and passing > specifying > > it as a data pointer when constructing the functions. However, this did > not > > work as the emacs_value objects does not seem to have a lifetime outsid= e > of > > the invocation of a native function. I haven't seen this documented > > anywhere, so that was a bit surprising at first. The fact that this > failed > > is the reason you see all the calls to env->intern everywhere. > > This was not always the case: the behaviour was changed by Philipp at > some point. We still have the make_global_ref and free_global_ref > functions in the API, which serve no purpose as a result (correct me > if I'm wrong). > Using make_global_ref is definitely intended to make objects usable across environments (i.e. you should be able to use them in any thread whenever any environment is active). If that's not the case, please report a bug. The alternative of using intern everywhere is also not too bad because it's much simpler and more obvious (no global state that you have to track carefully). I'd recommend only switching to global references if there is a significant performance penalty. --001a1143d6b807f440054dd8dd5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Aur=C3= =A9lien Aptel <aurel= ien.aptel+emacs@gmail.com> schrieb am Fr., 10. Feb. 2017 um 19:21=C2= =A0Uhr:

> I tried putting all the interned symbols in a struct and passing speci= fying
> it as a data pointer when constructing the functions. However, this di= d not
> work as the emacs_value objects does not seem to have a lifetime outsi= de of
> the invocation of a native function. I haven't seen this documente= d
> anywhere, so that was a bit surprising at first. The fact that this fa= iled
> is the reason you see all the calls to env->intern everywhere.

This was not always the case: the behaviour was changed by Philipp at
some point. We still have the make_global_ref and free_global_ref
functions in the API, which serve no purpose as a result (correct me
if I'm wrong).

Using make_global_re= f is definitely intended to make objects usable across environments (i.e. y= ou should be able to use them in any thread whenever any environment is act= ive). If that's not the case, please report a bug.
The altern= ative of using intern everywhere is also not too bad because it's much = simpler and more obvious (no global state that you have to track carefully)= . I'd recommend only switching to global references if there is a signi= ficant performance penalty.=C2=A0
--001a1143d6b807f440054dd8dd5a--