On upgrading

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

On upgrading

Jon Meredith
I have a few questions about upgrading.

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) ?

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.

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 ?

Thanks,

Jon


Reply | Threaded
Open this post in threaded view
|

On upgrading

Michał Ptaszek
When Erlang was designed we had very little memory compared to today.
A few MBytes total compared to GBytes today. That's why there are only
two versions of a module.

Today I'd go for an arbitrary number and use GC to remove unused code.

Cheers

/Joe


On Sat, Mar 30, 2013 at 3:58 PM, Jonathan Schneider
<jon>wrote:

> I have a few questions about upgrading.
>
> 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) ?
>
> 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.
>
> 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 ?
>
> Thanks,
>
> Jon
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130330/37add64f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

On upgrading

Matthias Lang-2
In reply to this post by Jon Meredith
Hi,

On Saturday, March 30, Jonathan Schneider wrote:

> 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) ?

The closest I know of is erlang:check_process_code(Pid, Module). Here's
a one-liner which does what you want, in this case for the 'io' module:

  lists:filter(fun(P) -> erlang:check_process_code(P, io) end, erlang:processes()).

> 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.

Exactly. Don't do that.

> Would it be possible to support not one but arbitrary old versions
> of modules?

Probably a bunch of work.

For well-behaved code, e.g. a gen_server, having arbitrary old
versions (AOV) won't make a difference; you'll only ever run
old code for a very short time.

One case where AOV would make a difference: code which which is
"eventually" well-behaved. Imagine a process blocked in
gen_tcp:accept/1. You've loaded debug code into a live system and now
want to re-load the regular code and go home, but can't until the next
TCP connect happens. A pragmatic way out of this example is to
generate a TCP connect. There are other examples where you can't do
that, e.g. code blocked in gen_tcp:recv/2.

With AOV, such a system will drop from running three versions of the
code to two, and then back to one. But that's not clearly better than
going home after starting something like:

  wait_and_hope() ->
    timer:sleep(5000),
    case code:soft_purge(my_module) of
      true -> load_new_code();
      false -> wait_and_hope()
    end.

Maybe someone has a more compelling real-world example.

Matt