|
From: | Stefan Monnier |
Subject: | Re: [Emacs-diffs] emacs-25 3eb93c0: Rely on conservative stack scanning to find "emacs_value"s |
Date: | Wed, 30 Mar 2016 17:30:58 -0400 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
> And zero years of experience with anything not statically linked into > Emacs core. Actually not exactly since we've used dynamic linking on the Windows side for a few years now. But I see no reason to expect any special issues showing up because of it in any case: none of the Lisp_Object low-level twiddling we do seems to depend in any way on whether code is linked statically or dynamically. >> The other scheme originally implemented was terribly inefficient > No it wasn't. It's one additional pointer dereference. I'm not talking about that. I'm talking about the cost of allocating/freeing those boxes to which you point. > And I'd bet you'd still love to just ship lisp.h with Emacs and make > (call-process "gcc" ...) to load modules. I would have been happy with it, but I'm also happy with a more abstract option like the emacs-module.h we have (save for the insane signal mangling, obviously). Stefan
[Prev in Thread] | Current Thread | [Next in Thread] |