[erlang-questions] Process Dictionary limitations??

[Michael Truog]

On 10/10/2012 06:40 PM, Charles Hixson wrote:
> 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.
>
Usually the State variable in the OTP behaviours is always a record, which is preprocessing syntactical sugar for tuples (similar to a struct in C, conceptually).  So, it provides constant time (O(1)) access to tuple elements based on field names (when reading elements, setting elements has more overhead... all memory is copied since variables are immutable in Erlang).  If you need dynamic field names, there are many options for various key-value data structures.  In OTP, dict, gb_trees, orddict (and array if your key type is always an integer).  If you need to use dynamic strings as key values, I have a trie here https://github.com/okeuday/trie.  However, it is best (most typical and maintainable) if you can rely on a record (tuple) for process state.  Within the state record, you can always define any dynamic lookups you might need or other data structures you wish to utilize.

Hope this helps make it clear that the key-value data structures available in separate modules (either within OTP or external to OTP) help to make sure you can create key-value lookups within Erlang code without utilizing the process dictionary.

The other direction you can go is to use ets which provides global storage in Erlang, managed by a process.  However, it is best to avoid global variables whenever possible.



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