[erlang-questions] Closures across module reloads, undocumented behavior?
Mon Aug 16 21:52:14 CEST 2010
On Mon, Aug 16, 2010 at 5:41 AM, Matthias Lang <> wrote:
> On Thursday, August 12, Nahuel Greco wrote:
>> But the desired behaviour is at least undocumented, it needs to be
>> defined and/or documented officially.
> It's not exactly official, but it's certainly useful: the "Barklund
> Draft" defines hot code loading quite carefully, starting on p.125.
> I think the behaviour you get from a patched system matches what the
> Barklund draft says will happen. Or have I misunderstood?
There is no mention of what happens with function references stored in
heap across modules reloads. The bug effect of an apparent automatic
"migration" of closures to the new module code made me search for that
explicit note. The R14A documentation mentions the case of a process
containing a fun referencing the old module in the
check_process_code/2 section, but it doesn't explicitly states the
closures will continue to reference the old module code when a new
version is loaded. In constrast, the Barklund Draft seems more
incomplete, because in his section 9.7 check_process_code/2 is
documented as only scanning the call stack, but the implementation
also scans the process heap, leaving undefined the closures related
I think the intuitive and intended behaviour, in the spirit of the
Barklund Draft, is the one your patch provides; no weird automatic
closure "migrations" and check_process_code/2 detecting a process as
using the old version when a fun in his heap points to it. Probably
closures continuing to point to the old version is taken as obvious
and with no need of clarification, but maybe an explicit note about
what happens with the function references in heap when reloading a
module would have made easier to classify the R14A behaviour as a bug.
OTP Team: will you apply the Matthias patch to trunk or there is a
reason to not use that patch?
More information about the erlang-questions