[erlang-questions] Erlang processes and state management design
Wed Oct 24 14:15:13 CEST 2007
Thanks a lot,
But you seem to not consider solution 2 (process dictionnary). Is
this because it is not efficient, or at least not more efficient than
Also, I read somewhere that the heap for processes in Erlang was
rather small for historical reasons. If I store data in the
parameters or in the process dictionnary, will I run into some limit?
Alternatively, I suppose the data for ETS structures are stored on
the node's heap and not in the process heap? Is this correct?
Le 24 oct. 07 à 12:22, Bengt Kleberg a écrit :
> the first 3 solutions will be gone after the process dies. ets tables
> are garbage collected when their ''owning process'' dies.
> i would recommend 1 until you get > 1000 items per process.
> or you could start with 1. keep the adding/removing/extracting
> hidden in
> a module and then switch to 3 using another module with the same
> name if
> you run into problems.
> Those were the days...
> EPO guidelines 1978: "If the contribution to the known art resides
> solely in a computer program then the subject matter is not
> patentable in whatever manner it may be presented in the claims."
> On 2007-10-24 12:00, Alexander Lamb wrote:
>> Hello again,
>> So, I am gradually understanding the design philosophy of an Erlang
>> On the one hand, functionnal programming is about having no state.
>> However, in the situation of a Web application, you obviously need to
>> keep some state otherwise you are back to PhP style (in the sense you
>> are recalculating everything at each request).
>> I went back to Joe's book and read again the chapter on processes.
>> as someone suggested earlier, I realized the state of an Erlang
>> can actually be kept in a process. So when designing an
>> application, you
>> indeed model the processes, then the state of the processes, then the
>> So for example, if I create a process for each user who logs in to a
>> program. Upon creation of the process I could fetch all the
>> features and
>> worklists the user has, then keep them in his process until he
>> logs out
>> (or after a given long timeout).
>> I can do that for every task which needs to keep a state between
>> Therefore, I have a question: where is it usuall or reasonnable to
>> the state of a process?
>> 1) in the parameters of the function we spawn
>> 2) in the process dictionnary
>> 3) in an ETS structure
>> 4) in a in-memory mnesia structure
>> I suppose it really depends on the amount of data and how it will be
>> modified (and if we want to keep persistent some session data
>> after the
>> process is killed).
>> Tell me if I am wrong, but the first two solutions will put data
>> on the
>> process stack and will be destroyed when the process is killed.
>> The two
>> other solutions will have to be cleaned out when the process is
>> Are there some guidelines?
>> For a user process, I might have 30 or 40 features in a list, some
>> values about his account, etc...
>> For a process managing (for example) browsing patients in a list,
>> I will
>> have the list of patients with the visits for the currently selected
>> patient, etc...
>> Thanks for any hints!
>> Alexander Lamb
>> Founding Associate
>> RODANOTECH Sàrl
>> 4 ch. de la Tour de Champel
>> 1206 Geneva
>> Tel: 022 347 77 37
>> Fax: 022 347 77 38
>> erlang-questions mailing list
> erlang-questions mailing list
4 ch. de la Tour de Champel
Tel: 022 347 77 37
Fax: 022 347 77 38
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions