From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 4 Oct 2015 12:34:15 -0700 Message-ID: <56117F37.9060808@dancol.org> References: <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RftJgFEbbflufEDsH2xsWmbT4ee56jUqP" X-Trace: ger.gmane.org 1443987277 6814 80.91.229.3 (4 Oct 2015 19:34:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 19:34:37 +0000 (UTC) Cc: =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 21:34:32 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 1Zip3F-00016r-T1 for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 21:34:30 +0200 Original-Received: from localhost ([::1]:43514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zip3F-0001VT-84 for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 15:34:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zip3A-0001Ut-Gp for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:34:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zip39-0008Oy-4c for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:34:24 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zip38-0008Nn-Pm; Sun, 04 Oct 2015 15:34:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=zrNcWNHQD7wWjQbiIVuovoIg/S7Xj9Y37IlB1xOEvh4=; b=HhJtae75Wnqx9X3WuhFmSvjq3jmMauo2mWF5ED62YDjElLo0vA91o3gorjxnGmobcxOQY7ko3xso1mbIdPJNqZ31Scw/qOM2MJv03uUtsAgXmSQ8hUOfMmcCF9Y0tENsrSmeaXr0Ti3bpsrq9s5svFHREzWLzSBUnJcQGACHqifLzLfa4VAgytt06nkxlCA+Fu2VOZ0i1UnWnM879MKsSSn42hplxoNo9I0ZQz8+VwMNiY+zZqRL4d/767begmzKOYpElBvY83tt44FhuMEYLTk5Z/gXEJTmE7uyMKjEKQQINNvbYO5013EnkPQe/FN9ecScjZMFNLen0sqZRVd/SQ==; Original-Received: from [2620:10d:c090:180::b4ee] (helo=[IPv6:2620:10d:c081:1101:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Zip37-00056l-77; Sun, 04 Oct 2015 12:34:21 -0700 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:190899 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RftJgFEbbflufEDsH2xsWmbT4ee56jUqP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/04/2015 02:41 AM, Philipp Stephani wrote: > > > > > > typedef struct emacs_value_tag* emacs_value; > > > > > > I think it's important that this is a pointer to a struct (for ty= pe > > safety and size correctness) rather than just an arbitrary type. >=20 > A typedef is exactly as typesafe. The question of whether to use a > struct or a typedef is aesthetic. I strongly prefer a typedef, just= like > pthreads, and I believe that the people who advocate using structs > directly are simply wrong. >=20 >=20 > Ah, I'm not against the typedef, I'm just asking whether you would make= > it part of the API contract that it's a typedef of a struct pointer, or= > whether it can be any type. The problem with defining it as a pointer type is that NULL is now the invalid sentinel value, which seems incompatible with both making this thing literally a Lisp_Object and Qnil having all zero bits. That's why I strongly prefer making emacs_value a _pointer_ to a Lisp_Object, where we store the Lisp_Object in an array owned by the emacs_env. This way, allocating local values is very cheap. > > Modules can use make_global_reference to allocate a global > reference > > (i.e., a GC root) for any emacs_value; modules must then free= > these > > references explicitly. > > > > All routines (except make_global_reference) that return > emacs_value > > values return local references. It's up to modules to regist= er > > long-lived references explicitly. > > > > > > In which cases would global references be necessary? >=20 > Any time you want to hold onto a lisp value outside the dynamic ext= ent > of your emacs_env. >=20 >=20 > Isn't the dynamic extent of the emacs_env the whole program, starting > from the module initializer? Not necessarily. An emacs_env is valid only for the current call into module code on the current thread. So if we call module-function-1, wait for it to return, then call module-function-2, the two calls can have different environments, and using local references from one might not be valid on the other. (This approach opens up very important optimizations in JNI, and it'd be good for us to use the same approach.) A global reference is just an emacs_env in a heap-allocated object we register as a GC root. (To answer the question another way: global references are GC roots.) --RftJgFEbbflufEDsH2xsWmbT4ee56jUqP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWEX83AAoJEN4WImmbpWBlIl4QAKsX+EhldK4oR2hxnDGxpHxs Ld2M6vmj7QYNWM8lwT1+XLwc7FV+OiKen/1q8ZMVCR4Rp9D2EfQG/4fqo0wVxetx G9yXpbg/FwxoU+vy9IIXIIJXeUJwrYpjj/cwVQJNM6TitVf4FJAYGtCsv/LQSxvH FuvCMAym3JE1q0nD5KLixbhdPormmwUHLDnPKBltkMdwI8YfWEYF+N6gdUf7XUpm 9L+EYvqBIV+Q9vGcEgpWpK3c97YC9heNhCFbZetuJ5iCWJDwppVyCzE9H1pARqjB bCRrjfOP93TmbnH5UPGi5kO4q2I8WUOcFM1I3tZOzND9hLQtVz0l/6msgh4vcMnP X2JTv1DJojFg/Oj781vIxWYtsNeW1IozS3VzDzBb7GXH3Hiu02u+dyO1HlUHtXD0 PGXstniw6rjifgS3kf24hebHF0L+7iRU1Q1nYdQycMKJnVBhxJdHN0jTExX/FYTK 78J35NWWeW8ZuDWdj5JaX72CyEiz57OdN0x2g5+A0LIuqMRD6faG+pEUPipB3dm+ jIid00S4jotArgtwIYFxZhPl/d0LKnCQinRSl82l5wzixB6lTPp79AoFFs1L6I+r T4SJGDm5DZaFsItRM3yCwzO7WAFsOw/E6F8zgR3jPaoS9CZj5yc5CriJCJ7QBHEF IEhqZHJYesYJSzc6mGEl =gN24 -----END PGP SIGNATURE----- --RftJgFEbbflufEDsH2xsWmbT4ee56jUqP--