[erlang-questions] Please help me relate a past project to Erlang, I'm trying to understand...

bill robertson billrobertson42+erlang@REDACTED
Thu Mar 19 02:19:45 CET 2009


So that is the deal.  I guess that makes sense, because when you're
waiting on a receive to return, you still have a stack frame don't
you?

I think I finally get it.

Thanks all!

2009/3/18 Robert Lally <rob.lally@REDACTED>:
> As I've been learning Erlang, this has been the hardest thing to get to
> grips with. The fact that I often don't need to explicitly store my state
> anywhere, it will hang out in a receive block waiting for me to get back to
> it seems counter-intuitive. I crave a neat, labelled pigeon hole to store my
> state in .. but I don't need it.
>
> Rob Lally.
>
>
> 2009/3/18 Thomas Lindgren <thomasl_erlang@REDACTED>
>>
>> ----- Original Message ----
>> > From: bill robertson <billrobertson42+erlang@REDACTED>
>> > To: erlang-questions@REDACTED
>> > Sent: Wednesday, March 18, 2009 3:59:07 AM
>> > Subject: Re: [erlang-questions] Please help me relate a past project to
>> > Erlang, I'm trying to understand...
>> >
>> > Thats good.  Now, to make it *stateful* (and this is the heart of the
>> > question).  Suppose you have the requirement to allow a web user to
>> > view the call as it is in progress and show them who is connected
>> > (telephone number), and how long they have been connected, and also
>> > who is disconnected and how long they were connected.
>> >
>> > To do this, you need to track three items for each participant.  The
>> > telephone number.  The start time, and a stop time.
>> >
>> > So network request comes in, we have to enumerate those pieces of
>> > information for it and send them back to the client.
>> >
>> > How would you implement this in a typical Erlang system?
>>
>>
>> The simplest approach is to use plain erlang and message passing.
>> Something like:
>>
>> start_conference_call(Name) ->
>>   spawn_link(
>>     fun() ->
>>       register(Name, self()),
>>       Empty_state = [],
>>       conf_call_loop(Empty_state)
>>    end).
>>
>> conf_call_loop(Callers) ->
>>   receive
>>      {join, Caller} ->
>>         Time = erlang:now(),
>>         conf_call_loop([{Caller, Time}|Callers]);   %% add a new caller
>>      {leave, Caller} ->
>>         conf_call_loop(delete_caller(Caller, Callers));  %% delete a
>> caller
>>     {message, From, Msg} ->     %% send message to all participants
>>         send_to_all(Callers, Msg),
>>         conf_call_loop(Callers);
>>     {status, Asker} ->   %% send status to asking process
>>         Asker ! {status, Callers},
>>         conf_call_loop(Callers);
>>     stop ->
>>         ok
>>   end.
>>
>> %% Client API
>> status(ConfCall) ->
>>   ConfCall ! {status, self()},
>>   receive
>>      {status, Callers} -> {status, Callers}
>>   end.
>>
>> ... (code for some left-out functions) ...
>>
>> So, the conference call process keeps its state as a list passed arounf in
>> conf_call_loop/1. Callers can join and leave and send messages to each
>> other, all by sending messages to this process. You can also ask for status
>> (which here just returns the list of callers and their join time) and stop
>> the process. So, the conference call process itself is just a tail recursive
>> function conf_call_loop/1 that processes messages forever (or until
>> stopped). The state = list of callers lives as long as the conference call
>> process.
>>
>> (Each caller would then itself be an erlang process, passing messages
>> to/from the telephony driver and conference call process and any others
>> involved.)
>>
>> Now, this is of course just a sketch, since the code is sloppy and you'd
>> want to handle more cases in practice, _but_ it demonstrates the very
>> simplest way to keep state.
>>
>> Best,
>> Thomas
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>
> --
> Blog : http://robertlally.com
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list