[erlang-questions] process dictionary, anyone?

Ulf Wiger (TN/EAB) <>
Mon Apr 30 11:11:39 CEST 2007


Torbjorn Tornkvist wrote:
> 
> Tony Rogvall skrev:
> > Hi !
> > 
> > I think most of us has used put/get at some point.
> > It will ALWAYS hit you back. You will spend hours trying to 
> locate the 
> > place where things went wrong. I do use put/get and I think 
> you will 
> > too.
> > But it's NOT a great little hack it's a disease.
> 
> Well spoken Tony!
> 
> To all Erlang newbee's: stay away from the process dicts!
> In fact, try to stay away from any destructive operation.
> 
> After 15 years of Erlang hacking I almost never use the 
> proc.dict (perhaps once every third year or so...:-)

I agree that it's easy to abuse the process dictionary,
but I can't see that using ets is any better. So the 
advice should be to avoid certain programming patterns.

Most importantly, don't sprinkle side-effects all over
your code, but try keep as much of your code as 
possible side-effect free.


Comparing the process dictionary an ets, there are 
pros and cons with each:

- process dictionary is a linear hash table, like 
  ets sets (but not exactly the same implementation)

- there's no copying when accessing the process 
  dictionary, but then again, there is GC. With ets,
  it's the other way around. (We have code where the
  process heap is sized so that all garbage of 
  short-lived processes fits on the heap. This means
  no copying - no GC).

- ets tables can be made to survive a process crash
  (by making some other process the owner). This can
  be a good thing, but forces you to use public ets
  tables (bad thing). I believe most ets tables in 
  use are public, which in a sense makes them worse
  than the process dictionaries.

- On a few occasions, it is actually useful to let
  several processes write to the same ets table, 
  but in most cases where it's contemplated, it's 
  a very bad idea.

- The contents of the process dictionary is included
  in crash reports, while the contents of ets tables
  are automatically wiped out when the owner dies -  
  bad for debugging, unless you make another process
  the owner, and make the table public, so you can
  write to it (which means everyone else can write 
  to it too - bad) 

- Of course, storing huge amounts of data in the 
  proc dict is bad because (a) it's GC:d, and 
  (b) all the data is dumped into the SASL crash
  reports, which are (by default) pretty-printed
  to the tty - potential diaster.

- ets has much better search and fold facilities
  (the process dictionary has practically none).

- Allowing many processes to write from an ets 
  table _can_ be very useful. This could be done
  with the process dictionary as well, but at 
  the moment, the only option available is to 
  read the entire dictionary at once (through
  process_info(P, dictionary). This involves 
  a copy, btw, just like with ets.

In short, I'd say that the process dictionary is 
no worse than any other kind of side-effect, but 
has some fairly unique advantages as well.

BR,
Ulf W

> -----Original Message-----
> From:  
> [mailto:] On Behalf Of 
> Torbjorn Tornkvist
> Sent: den 30 april 2007 10:12
> To: 
> Subject: Re: [erlang-questions] process dictionary, anyone?
> 
> Tony Rogvall skrev:
> > Hi !
> > 
> > I think most of us has used put/get at some point.
> > It will ALWAYS hit you back. You will spend hours trying to 
> locate the 
> > place where things went wrong. I do use put/get and I think 
> you will 
> > too.
> > But it's NOT a great little hack it's a disease.
> 
> Well spoken Tony!
> 
> To all Erlang newbee's: stay away from the process dicts!
> In fact, try to stay away from any destructive operation.
> 
> After 15 years of Erlang hacking I almost never use the 
> proc.dict (perhaps once every third year or so...:-)
> 
> Cheers, Tobbe
> 
> > 
> > Happy hacking
> > 
> > /Tony
> > 
> > 
> > 
> > On 30 apr 2007, at 00.53, Bob Ippolito wrote:
> > 
> >> You can represent any non-functional construct with 
> message passing. 
> >> A side-effect is a side-effect... Erlang is clearly a hybrid 
> >> language, but it has a very useful subset that is purely 
> functional. 
> >> Much of what I've read in the standard library is written in that 
> >> purely functional subset, and the syntax and features of the 
> >> language/VM seem like they're designed to encourage and 
> support mostly that subset.
> >>
> >> Using the process dictionary is a great little hack that saves you 
> >> from refactoring a bunch of code to include an extra state 
> variable...
> >>
> >> -bob
> >>
> > 
> 
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 




More information about the erlang-questions mailing list