Doubt about funs

[Ulf Wiger]

I basically agree with Martin, but...


On Wed, 21 Feb 2001, Martin Bjorklund wrote:

>"Erik Johansson" <happi@REDACTED> wrote:

>>  has the same effect as
>> spawn(m, f, [X1, ..., Xn])
>
>What you describe is not how it works today:
>
>====================================
>-module(t).
>-export([t/0]).
>
>
>t() ->
>    spawn(fun() -> loop() end).
>
>loop() ->
>    receive
>	ok ->
>	    loop()
>    end.
>====================================
>1> c(t).
>{ok,t}
>2> P = t:t().
><0.32.0>
>3> process_info(P, current_function).
>{current_function,{t,loop,0}}
>4> l(t).
>{module,t}
>5> process_info(P, current_function).
>{current_function,{t,loop,0}}
>6> l(t).
>{module,t}
>7> process_info(P, current_function).
>undefined


Erm, what did you intent to demonstrate here?
P crashes, but that doesn't really have anything to do with the
fun. It's because t:loop() executes in the old module.
If you change loop() like this:

loop() -> 
    receive
	ok ->
	    t:loop()
    after 1000 ->
	    t:loop()
    end.

then P won't crash.

Indeed, if you make a stack trace on P, you will see that there is
no reference to the fun on the stack (if I read the stack trace
correctly):

39> erlang:process_display(P, backtrace).
program counter = 0x19a8f4 (t:loop/0 + 4)
cp = 0xed830 (<terminate process normally>)
arity = 0
true


The main gripe about long-lived funs is exactly that they sometimes
surprise you during code change. Upgrades are hard enough as it is.
This could perhaps be remedied -- it's certainly improved a lot
already, compared to you only needed to recompile to break all
references to a fun.

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB