[erlang-questions] Erlang processes and state management design

Bengt Kleberg bengt.kleberg@REDACTED
Wed Oct 24 15:21:27 CEST 2007


greetings,

i did not consider using 2 (process dictionary) since i have found it to 
be a problem when writing tests and also when trying to figure out what 
went wrong on a live system.

the heap for a process will grow when needed. and shrink, too. so you 
should not worry about it starting out small. unless you know that it 
must become big and want to make things a small amount faster.

since ets is garbage collected with the process i would assume (i could 
be wrong) that ets uses the process heap.


bengt
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 14:15, Alexander Lamb wrote:
> 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 parameters?
> 
> 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?
> 
> Thanks,
> 
> Alex
> 
> Le 24 oct. 07 à 12:22, Bengt Kleberg a écrit :
> 
>> greetings,
>>
>> 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.
>>
>>
>> bengt
>> 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 
>>> application.
>>> 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. And, 
>>> as someone suggested earlier, I realized the state of an Erlang program 
>>> 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 
>>> messages.
>>>
>>> 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 
>>> requests.
>>>
>>> Therefore, I have a question: where is it usuall or reasonnable to keep 
>>> 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 killed.
>>>
>>> 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!
>>>
>>> Alex
>>> --
>>> Alexander Lamb
>>> Founding Associate
>>> RODANOTECH Sàrl
>>>
>>> 4 ch. de la Tour de Champel
>>> 1206 Geneva
>>> Switzerland
>>>
>>> Tel:  022 347 77 37
>>> Fax: 022 347 77 38
>>>
>>> http://www.rodanotech.ch
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://www.erlang.org/mailman/listinfo/erlang-questions
> 
> --
> Alexander Lamb
> Founding Associate
> RODANOTECH Sàrl
> 
> 4 ch. de la Tour de Champel
> 1206 Geneva
> Switzerland
> 
> Tel:  022 347 77 37
> Fax: 022 347 77 38
> 
> http://www.rodanotech.ch
> 
> 
> 



More information about the erlang-questions mailing list