*** SPAM *** Re: fun opacity

[Raimo Niskanen]

If the originating module is reloaded with a new, the old code is
retained until all references from funs in all processes has 
disappeared (been garbage collected). Therefore one more code 
upgrade of that module will kill the processes holding funs
refering to the old module since there can be only two
versions of a module - current and old.

To be precise:
  code:load/1       loads a module but fails if there is an old version.
  code:purge/1      deletes the old code if there is such. If processes
                    execute the code or if processes hold funs refering
                    to the code they are killed.
  code:soft_purge/1 deletes the old code if it can be done without
                    killing any processes.
  c:l/0             does code:purge(M), code:load(M).

See also the erlang man page for code(3).

What the release_handler does is probably something similar.

So, if you want a fun that is usable over code upgrades, you can
use the ancient {M,F} tuple funs, or apply(M, F, Args). There might
be a replacement for the tuple funs coming in a release one day
because the HIPE group does not allow them.



erlang@REDACTED (Peter-Henry Mander) writes:

> On Mon, 10 Jan 2005 07:17:49 -0500
> Vance Shipley <vances@REDACTED> wrote:
> 
> > On Mon, Jan 10, 2005 at 11:09:18AM +0000, Peter-Henry Mander wrote:
> > }
> > }  I presume this is an implementation of a callback, or something like that?
> > 
> > Yes, precisely.
> > 
> > 	-Vance
> > 
> 
> Would a reference serve your purpose, or is there something in the
> input-context you wish to preserve?
> 
> What would happen if the originating module was reloaded with a modified
> version? Will the old version of the code still remain resident until
> the fun returns home to execute? I suspect that the code loading logic
> may not know about the itinerant fun. The results may be undetermined.
> 
> I'm curious to know because I tend to use funs where, upon reflection,
> simpler data types would suffice with less potential unanticipated
> results, and more potential to expand capability, because fewer usage
> assumptions are made too early.
> 
> Pete.
> 
> P.s. I feel the caffeine effect...
> 
> -- 
> "The Tao of Programming
>  flows far away 
>  and returns 
>  on the wind of morning."
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB