[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
- Re: Dynamic loading progress, Ted Zlatanov, 2015/08/19
- Re: Dynamic loading progress, Stephen Leake, 2015/08/20
- Re: Dynamic loading progress, Aurélien Aptel, 2015/08/23
- Re: Dynamic loading progress, Tom Tromey, 2015/08/24
- Re: Dynamic loading progress, Stefan Monnier, 2015/08/24
- Re: Dynamic loading progress, Paul Eggert, 2015/08/24
- Re: Dynamic loading progress, David Kastrup, 2015/08/25
- Re: Dynamic loading progress, Stefan Monnier, 2015/08/25
- Re: Dynamic loading progress, Paul Eggert, 2015/08/26
- Re: Dynamic loading progress, Aurélien Aptel, 2015/08/27