[erlang-questions] Process Dictionary limitations??

[Charles Hixson]

On 10/10/2012 04:21 PM, Michael Truog wrote:
> On 10/10/2012 03:55 PM, Charles Hixson wrote:
>> I'm choosing a language to implement a ... well, neural network is 
>> wrong, and so is cellular automaton, but it gives the idea.  Anyway, 
>> I'm going to need, in each cell, a few stateful items, e.g. 
>> activation level.
>>
>> When I look at what Erlang can do, I see that the Process Dictionary 
>> looks as if it would serve my needs, but then I am immediately warned 
>> not to use it, that it will cause bugs.  These stateful terms will 
>> not be exported from the cell within which they are resident.  Is 
>> this still likely to cause problems?  Is there some better approach 
>> to maintaining state?  (I can't just generate a new process, because 
>> other cells will need to know how to access this one, or to test that 
>> it has been rolled out.)
>>
> This explains some basics about the process dictionary: 
> http://www.erlang.org/course/advanced.html#dict
> Quoted below:
>
>   * Destroys referential transparency
>   * Makes debugging difficult
>   * Survives Catch/Throw
>
> So, it is much better to use variables, so side-effects are more 
> explicit (i.e., function variables).  This is the equivalent to the 
> State variable of a gen_server behaviour 
> (http://www.erlang.org/doc/man/gen_server.html).  Depending on the 
> expected state-handling, you might want a gen_server, a gen_event, or 
> a gen_fsm for each cell.  Otherwise, if you want to avoid OTP 
> behaviour usage, you could just do plain Erlang code, but your code 
> might then be more error-prone (especially since you are asking this 
> question).
>
Thank you.  That confirms the recommendation against using the process 
directory, though I will admit that I can't see any way that your 
proposed alternatives could replace it.

-- 
Charles Hixson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121010/3f396552/attachment.htm>