[erlang-questions] Access to process dictionary
Eric Pailleau
eric.pailleau@REDACTED
Mon Dec 24 16:30:28 CET 2018
Yeah,
A common workaround is to prefix all your entries with the name of your module, but it is not a full guarantee.
'Use the state, Luke... '
Envoyé depuis mon mobile
---- Attila Rajmund Nohl a écrit ----
>The same is true for e.g. public named ETS tables or even for modules. If a
>different library uses the same name, it's a problem.
>
>2018. dec. 24., Hét 0:10 dátummal Eric Pailleau <eric.pailleau@REDACTED>
>ezt írta:
>
>> Hi,
>>
>> Yes you are right. I forgot this.
>>
>> Anyway process dictionary should be avoid because same dictionary entry
>> name could be used in different library code called in same process.
>>
>> Let say you create an entry 'foo' in your code, but you use external code
>> having same idea. Your dictionary can be overwritten. It is not safe.
>>
>> Envoyé depuis mon mobile
>>
>>
>> ---- Attila Rajmund Nohl a écrit ----
>>
>> Eric Pailleau <eric.pailleau@REDACTED> ezt írta (időpont: 2018. dec.
>> 23., V, 10:13):
>> >
>> > You should however avoid to use process dictionaries if possible.
>> >
>> > It is handy to store things, but generally a sign that your code is
>> missing something.
>> >
>> >
>> > For instance if you face some processes crashes, your process dictionary
>> will be lost, while using states in OTP libs will be shown in crash report.
>> Easier for debugging.
>>
>> I do see the process dictionary in crash reports (I'm not sure if
>> lager puts it there or it is there by default). Process dictionary is
>> useful for read-only data (i.e. not state): put stuff there at process
>> startup, then don't have to worry about passing yet an other value
>> around, all function can access that piece of data.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20181224/2035b055/attachment.htm>
More information about the erlang-questions
mailing list