Doubt about funs

Ulf Wiger etxuwig@REDACTED
Wed Feb 21 10:51:21 CET 2001

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:
>t() ->
>    spawn(fun() -> loop() end).
>loop() ->
>    receive
>	ok ->
>	    loop()
>    end.
>1> c(t).
>2> P = t:t().
>3> process_info(P, current_function).
>4> l(t).
>5> process_info(P, current_function).
>6> l(t).
>7> process_info(P, current_function).

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() -> 
	ok ->
    after 1000 ->

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

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

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.

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

More information about the erlang-questions mailing list