emacs-devel
[Top][All Lists]
Advanced

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

Re: Dynamic loading progress


From: Stefan Monnier
Subject: Re: Dynamic loading progress
Date: Sun, 03 May 2015 20:16:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>>> I would go simple for now: always make a copy of the string using UTF-8
>>> encoding in the args, assuming that the majority of C modules can deal
>>> with it, and we can stop worrying about string sharing and encoding for
>>> now (we can revisit them later). We should free the copy right after
>>> calling so the module doesn't have to free it.

I don't like this idea of making copies just to avoid memory management.
Especially since we already have a GC available to solve this problem.
But I missed the context, so I don't really know what I'm talking about.

SL> We also need to document the GCPRO issues;
> ...
SL> should the module do GCPRO around the funcall, or does the funcall
SL> handle that?
> IMHO Emacs should manage memory, period. Any time modules are given that
> responsibility, it's an opportunity for bugs and a premature
> optimization.

It's an illusion to think that all memory management can be moved to the
Emacs side.  But I think the best way to move most of it to the Emacs
side is to let the modules benefit from the Emacs's GC, and hence export
the "GC protocol" to the modules side.

As mentioned elsewhere, we probably want to skip the GCPRO part of the
protocol (and hence only support dynamic loading on those platforms
where we use conservative stack scanning), so as to move even more of
the memory management onto the Emacs's side.

SL> Also, we need to do something about the doc strings for lisp objects
SL> declared in modules. I don't think they need to be available before the
SL> module is loaded; if a particular author wants that, they can define an
SL> elisp wrapper with autoloads.

Agreed.  The same holds for .el files.  The only difference is that for
.el files we have autoload.el which can auto-generate the "wrapper with
autoloads".  Maybe we could create a similar system for dynloaded
packages, but there's no hurry for it.


        Stefan



reply via email to

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