emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress


From: Daniel Colascione
Subject: Re: Dynamic loading progress
Date: Mon, 19 Oct 2015 20:13:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/19/2015 08:05 PM, Tom Tromey wrote:
> Daniel> Yes, we do. I'd prefer eq, since the definition will never change, and
> Daniel> having a nice convenient way to access eq is useful in more situations
> Daniel> than a specialized test for eq nil.
> 
> Both are useful and it is cheap to provide a method, so why not have
> both eq and nilp?

I have no objection to including both.

> Daniel> Maybe we should actually get rid of get_environment and rely entirely 
> on
> Daniel> passed-in environment objects. It simplifies the API and avoids
> Daniel> definitional problems.
> 
> Yeah, I brought this up earlier and I still don't understand the reason
> for the runtime/environment split.

A runtime describes Emacs as a whole. It lives forever and has no thread
affinity. An environment represents a specific stack activation of an
Emacs module function. It has thread affinity. Because environments have
thread affinity, we can very cheaply store local references, error
context, and whatever else we want in them. We could probably get away
with only defining environments, but then we'd have no way to allow
routines to call Emacs routines at any time.

(Useful future runtime routines might be "attach this thread to the Lisp
engine", "send QUIT to the main thread", "abort spectacularly", "get
Emacs version", and so on.)

>>> 4. Some of the function (free_global_ref, the int/float extractors)
>>> don't return emacs_value and have no clear way to signal an error.
>>> For these function the caller always has to use
>>> check_error/get_error. Is that good enough?
> 
> Daniel> free_global_ref, like all resource-releasing functions, should be
> Daniel> infallible. For other functions, asking users to check the error state
> Daniel> after a call is fine, although we should also return reasonable dummy
> Daniel> values (0 and NaN, probably) as well in case they don't.
> 
> It might be handy if there was a special emacs_value meaning that an
> error occurred.

We have a perfectly good sentinel: NULL. NULL will never be a valid
local or global reference, so it's safe to use it to indicate that
something went wrong.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]