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, 23 Aug 2015 18:26:51 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> - Local values which are created/can-be-freed inside the module function.
>
>     a = make_string("foo")
>     b = make_string("bar")
>     len = funcall(eval, 1, [length_sym, b])
>     // a (and b?) might be invalid now if the GC was triggered inside
> the funcall call.
>
> In the core Emacs code, we have the GCPRO macro to deal with that use-case.

GCPRO is only needed if we don't use conservative stack scanning.
Conservative stack scanning is used by 99.9% of Emacs builds (so much so
that there are always latent bugs in the GCPRO code because it sees very
little testing), so I think it's perfectly acceptable to ignore the
remaining 0.1%.

IOW we don't need to worry about local Lisp_Object values: they'll be
found by the conservative stack scanner.

> - Values created and reused between 2 module calls.
>
>     emacs_value global_a;
>
>     module_func_A()
>         global_a = make_string("a")
>
>     module_func_B():
>         // global_a might be invalid now if the GC was triggered
> between func_A and func_B
>         return global_a
>
> In the core Emacs code, global_a is usually a defvar.

We just need to export the equivalent of "staticpro" (ideally, this
should keep track of which module called it, so that we can
automatically "unpro"tect those vars when/if the module is unloaded).

> Daniel was talking about tables mapping emacs_value to Lisp_Object,

I don't want to have to convert between emacs_value and Lisp_Object,
they should be one and the same.


        Stefan



reply via email to

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