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 02:10:43 -0700 Message-ID: <5610ED13.1010406@dancol.org> References: <838ugdf251.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qJRN1dKAUA6rUff9Mju7aKmgODDFdlSkR" X-Trace: ger.gmane.org 1443949899 9284 80.91.229.3 (4 Oct 2015 09:11:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 09:11:39 +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 11:11:29 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 1ZifKG-0000FQ-Nb for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 11:11:24 +0200 Original-Received: from localhost ([::1]:41735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZifKG-00005D-5x for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 05:11:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZifJn-00084F-Up for emacs-devel@gnu.org; Sun, 04 Oct 2015 05:10:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZifJk-0003LB-OH for emacs-devel@gnu.org; Sun, 04 Oct 2015 05:10:55 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZifJk-0003L0-Br; Sun, 04 Oct 2015 05:10:52 -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=hHq7ehMUwQ9ByRaxGl1YyGExkDMm0m+dP78qBWeFtu4=; b=R37e7QGmMhjCh+puw+l2TAqkSBIIQl+5EIOyQZ1MbWKB+YylqMImQmm+fPkhLrQiz8YLkNnUpbLIPEPvecWJGhTNxec0rVJKxcvxe+B3SstbJNg0pYjUQaCkq3LM8rg4T10+LJZGzVfCNoXWlFNHXEW2hC390yhATz4JlI4UKcFrw0r0512IDCnFf7GU0l0h4hMAZJTKCUNQM8e/Ibzz1WKKEjfEAZA0cZbbSFBEUfOens045ohAG7v11ovikcY2oSTBBFRpRgED2ANb92E/cFMteZJF/4muxccJAxHDTTced6m0sb0v674sOSt1UgTk1sQx01iQTQVHseq9ebZt7g==; Original-Received: from c-24-16-208-239.hsd1.wa.comcast.net ([24.16.208.239] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZifJg-0002DL-1v; Sun, 04 Oct 2015 02:10:48 -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:190859 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qJRN1dKAUA6rUff9Mju7aKmgODDFdlSkR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/04/2015 01:57 AM, Philipp Stephani wrote: > Daniel Colascione > schrie= b > am So., 15. Feb. 2015 um 21:21 Uhr: >=20 > Here's a broad outline of what I have in mind. >=20 >=20 > Thanks, that looks really good. Just a few minor issues that I > encountered over the last couple of weeks. > =20 >=20 > Thread-local environments > ------------------------- >=20 > The `get_environment' member lets us do anything else interesting. = As > in Java, environments are thread-local. We only support one thread = for > the moment, so this constraint is easy to enforce. (Just abort if w= e > use an emacs_env off the main thread.) >=20 >=20 > Would you really abort, or rather use the error handling functions? We > should be able to make the error values thread-local so that calling a > function from the wrong thread would be the equivalent of raising a > signal, giving the caller a chance to react. Otherwise the burden of > remembering the correct thread would be on the caller's side. If we abort, thread mismatch is a programming error, and we can omit optionally the check for performance. If we fail in some recoverable way, we have to perform the thread check every time, since it's now contractual. > =20 >=20 > typedef struct emacs_value_tag* emacs_value; >=20 >=20 > I think it's important that this is a pointer to a struct (for type > safety and size correctness) rather than just an arbitrary type. 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. > typedef emacs_value (*emacs_subr)( > emacs_env* env, > int nargs, > emacs_value args[]); >=20 >=20 > Could we give this a void* data parameter for storing arbitrary user > data? This is common for callbacks in C interfaces and allows C++ users= > to store C++ objects in the pointer. This can be implemented using > another save pointer. Yes, of course. > =20 >=20 >=20 > emacs_value (*funcall)( > emacs_env* env, > emacs_value function, > int nargs, > emacs_value args[]); >=20 >=20 > Does function have to be a function object, or can it be a symbol? I.e.= > is the user supposed to call symbol-function first? It'll have the same semantics as Ffuncall, so we'll be able to call a symbol or a function. > int64_t (*fixnum_to_int)( > emacs_env* env, > emacs_value value); >=20 > emacs_value (*make_fixnum)( > emacs_env* env, > int64_t value); >=20 >=20 > What's the behavior of these functions if the source would not fit into= > the result? Undefined behavior, abort(), raising a signal? I think we can do a range check fairly inexpensively, so just failing is probably fine. Code that ignores the possibility of failure will just abort later when it tries to misuse the API. If that's too expensive or error prone, we can just convert to an unspecified value when out of range (in practice, lopping off the extra bits). > Modules can use make_global_reference to allocate a global referenc= e > (i.e., a GC root) for any emacs_value; modules must then free these= > references explicitly. >=20 > All routines (except make_global_reference) that return emacs_value= > values return local references. It's up to modules to register > long-lived references explicitly. >=20 >=20 > In which cases would global references be necessary? Any time you want to hold onto a lisp value outside the dynamic extent of your emacs_env. > Like JNI, we can just declare that it's illegal to call all but a f= ew > specially-marked functions (like global reference deregistration) w= ith > a pending error. >=20 >=20 > What's the behavior if other functions are called? abort()? abort in check mode; unspecified when optimizing for performance. > =20 >=20 > If Lisp signals or throws, `funcall' returns NULL. >=20 >=20 > Hmm, with the current implementation emacs_value is just the same as > Lisp_Object, i.e. not a real pointer, so NULL doesn't have specific > semantics. Should it return Qnil instead and force the user to use > check_error? I thought we make Qnil equal zero. In any case, I *don't* like the idea of Lisp_Object being emacs_value. I'd much rather emacs_value be a pointer to a Lisp_Object, solving this problem completely. > 3) How exactly do we represent catch/throw values? >=20 >=20 > I've thought about this a bit, and I think it would be simplest to add = a > new function env->set_throw and have get_error and check_error return a= n > enum { normal, signal, throw }. One could come up with something like > creating a list (error-kind error-tag error-value), but it looks like > the module implementation would create such lists only for the module > code to convert them back, so it's simpler to represent the two kinds o= f > non-local exits directly in the interface. I'm fine with a list; keep in mind that we'll need to handle OOM somehow, so I'd suggest an opaque type. > 4) Do we need to use int64_t for integers? >=20 >=20 > Maybe just intmax_t and a static check that that is larger than an Elis= p > integer? Why make the behavior vary depending on what intmax_t is? At least int64_t is nice and explicit. --qJRN1dKAUA6rUff9Mju7aKmgODDFdlSkR 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 iQIcBAEBCAAGBQJWEO0TAAoJEN4WImmbpWBlZ5YP/i4PWSvVMwF8VWik72w1yybE R6lpdWV3yZCm+TG7DdGgWPlnqvrpc23yrLNAQ+EgNVX6/Ys+fczod7g10hHVgqPp PlWonSvA4y/kX6hLMhRc2/EsERnTNQ2rqSddK5RhRgXA/1qV2lYKOCAd+9z8jf+r zKG/m1pxzJg0D4eLb6e1CzQkgFt2YF7PbpJwFK45EhAhYWBiNKYBf6e4/pcAv565 x6xx0mfJVrcGmxZZmFUT7hm6W2gDuc8yt76G1OIniYQMynSY5rKwVVzxlO4XoSzI yPKd2QIVSMNE9RYDVMcaUhkwPyiiJkAVoU/rERd6dwGdfY2eJEpraHgVmPorR79f VqOMvvYBMRAY6XZZT+YuXsHhnU+dud7ZbPnsmzJ7AjDeeoh0nM4HE/jCPMLpT9dw 7/S+elHwAbH83j++/nhOgaiwHSgxF2OtsSDDCyPRSued7lYl9evD/ltyEEygs3Bx wumtexb1VTI+amPtYBb3QaQu6xPqyeBTo7Lk2b7xRSHbjWb+0tLnbu6uNXTWO7gI ENS71wx5Ucw+leQ3z7G+mmwUZZ/4FDT4VhIMD+NqMBVf+qcBWxjuRzpHMED+hwc8 XicNWUQzz6ykRh60cn9VxfXFW69YIhK4qHn0FX79aHBhwcW9x2+Tk/u5zQp9fMjY gVl8/Ls4mS32XhvDXOB4 =WTtI -----END PGP SIGNATURE----- --qJRN1dKAUA6rUff9Mju7aKmgODDFdlSkR--