<div dir="ltr">When Erlang was designed we had very little memory compared to today.<div style>A few MBytes total compared to GBytes today. That's why there are only</div><div style>two versions of a module.</div><div style>
<br></div><div style>Today I'd go for an arbitrary number and use GC to remove unused code.</div><div style><br></div><div style>Cheers</div><div style><br></div><div style>/Joe</div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sat, Mar 30, 2013 at 3:58 PM, Jonathan Schneider <span dir="ltr"><<a href="mailto:jon@axismilton.ltd.uk" target="_blank">jon@axismilton.ltd.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a few questions about upgrading.<br>
<br>
soft_purge/1 must know at some level which processes are still running the old version of a module. Does this function have a friend that returns a list of identifiers of processes that are getting in the way (that would die in a subsequent module load) ?<br>
<br>
The problem case is where a process has called through the module that wants upgrading and can't easily be tickled to let go of it. Obviously one would try not to have code arranged like that.<br>
<br>
Would it be possible to support not one but arbitrary old versions of modules ? Admittedly I don't understand the VM's workings but it seems to be the cost would be memory taken up by beam code. Was this ever considered during Erlang's design or indeed for the future ?<br>
<br>
Thanks,<br>
<br>
Jon<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>