[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: |
Fri, 06 Mar 2015 10:22:30 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
On 03/05/2015 09:14 PM, Stefan Monnier wrote:
>>>> * fixnum <-> int64_t is the only type conversion supported
>>> Not sure I understand: can the C side see "Lisp_Object" (presumably as
>>> an opaque type)?
>> As I'm imagining the system, no. Access is indirected. That insulates C
>> code from Emacs GC requirements and lets us easily support global
>> references.
>
> But that forces a completely manual management of Lisp_Object
> references, making the interface a lot more painful to use.
> I must prefer exposing staticpro and conservative stack scanning.
Reasonable people can differ on the conservative scanning issue (JSC
does it; V8 and Java don't). If we bake the assumption of conservative
scanning into the interface, we're going to regret it later. In
practice, manually managing references is no trouble at all since most
Lisp->C code is call-response, and we automatically unwind references
when C functions return.
I have to insist on not requiring staticpro, at least in its present
form. Registration of new GC roots (i.e., global references) must be
dynamic. You can't possibly predict the reference models modules might
want to use.
signature.asc
Description: OpenPGP digital signature
Re: Dynamic loading progress, Stephen Leake, 2015/03/05
Re: Dynamic loading progress, Stephen Leake, 2015/03/05
Re: Dynamic loading progress, Stephen Leake, 2015/03/16