Erlang/OTP Forums

Author Message

<  Erlang questions mailing list  ~  Process Dictionary vs Proplist in Web Frameworks

ngocdaothanh
Posted: Wed Oct 28, 2009 11:48 am Reply with quote
User Joined: 06 Dec 2008 Posts: 43
Hi,

Web frameworks are normally designed as layers (web server ->
middleware -> front controller -> controller -> action -> view ->
etc.). Data needs to be passed from one layer to another. There are 2
ways to pass:
1. Proplist (environment variables)
2. Process dictionary

The 2nd way:
* Is Simple and natural in Erlang because normally one HTTP request is
processed by one process.
* Makes application code which uses the framework appear to be clean,
because application developer does not have to manually pass an ugly
proplist arround and arround.

I want to ask about the (memory, CPU etc.) overhead of process
dictionary, compared to proplist. Which way should be used in a web
framework?

Thanks.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Post received from mailinglist
View user's profile Send private message Send e-mail
steved
Posted: Wed Oct 28, 2009 10:19 pm Reply with quote
User Joined: 29 Apr 2008 Posts: 78
I believe the art of using the PD is to stick rigorously to "write
once".

/s


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Post received from mailinglist
View user's profile Send private message
nem
Posted: Thu Oct 29, 2009 11:41 am Reply with quote
User Joined: 29 Nov 2007 Posts: 25
Ngoc Dao <ngocdaothanh@gmail.com> writes:

> Hi,
>
> Web frameworks are normally designed as layers (web server ->
> middleware -> front controller -> controller -> action -> view ->
> etc.). Data needs to be passed from one layer to another. There are 2
> ways to pass:
> 1. Proplist (environment variables)
> 2. Process dictionary
>
> The 2nd way:
> * Is Simple and natural in Erlang because normally one HTTP request is
> processed by one process.
> * Makes application code which uses the framework appear to be clean,
> because application developer does not have to manually pass an ugly
> proplist arround and arround.
> I want to ask about the (memory, CPU etc.) overhead of process
> dictionary, compared to proplist. Which way should be used in a web
> framework?

I would strongly advise against using the process dictionary to pass
data between part of an erlang web framework.[1]

You say that "normally one HTTP request is processed by one process" -
by using the process dictionary you require that this is the case for
all code that uses your framework. By making this decision, you are
tying the hands of the users of your framework. They can no longer
choose the process model that suits their problem and must use a one
process per request design. In erlang it's quite common to hand requests
off to other processes, possibly on other nodes, for execution to
balance load, to move computation closer to needed resources, to turn
synchronous tasks into asynchronous ones, to alter process memory
profile, to isolate failures and so on. The use
of the process dictionary precludes all these approaches.

You also say that using the process dictionary "makes application code
which uses the framework appear to be clean". From the point of view of
the maintenance programmer, nothing could be further from the
truth.

Good erlang code does not use the process dictionary. Erlang programmers
usually only have to think about the function body and arguments to work
out what its going to do. Sprinkling 'get' and 'put' through the code
means that an erlang programmer trying to understand your code now has
to read all the code to figure out why something is happening. The order
in which functions are called becomes important. The behaviour of
functions in other modules becomes important because now there's a
back-channel to propagate bugs, er, state between parts of the code.


As a (curmudgeonly) future web framework user, I would almost certainly
not choose a framework based on the use of non-erlangy features[2] such
as the process dictionary firstly because the code would be more difficult to
understand when someone would need to maintain it and secondly because
the process dictionary would prevent me from using a different process
model if I needed to.

Using a proplist or 'dict' or some opaque datastructure and an API
module is the natural, erlangy way to solve your problem.

Good luck with your framework,
--
Geoff Cant

[1] More generally, I would strongly advise against using the process
dictionary.
[2] Ditto for parameterized modules and hierarchal module names[3]
[3] I'm already guilty of this, but promise not to do it again.


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Post received from mailinglist
View user's profile Send private message
kagato
Posted: Thu Oct 29, 2009 8:52 pm Reply with quote
User Joined: 30 Dec 2007 Posts: 85
I'd say no, for a few reasons.

1. It makes it difficult if you ever do need to split stuff up into
multiple processes. As soon as you need a "helper" process, all of
your data is inaccessible.
2. It makes it difficult to debug via tracing. You can trace
function calls, tracing changes to the process dictionary is a bit
more hairy.
3. If you want to "hide" the proplist, just pass around some sort of
"request" record. Then you don't see it unless you access the
record. Or use macros and message a "request" process for the data.
4. If you use Mnesia, transactions can be retried, so you may end up
with your mutations happening multiple times if anything happens
inside of a transaction.

I don't deny that Erlang needs some better syntax and conventions for
passing data around (preferably via namespace magic like Ruby or
Python), but the process dictionary can break a quite a few
assumptions and break quite a few useful patterns. This could be fine
if you're the only one writing the code, but you the process
dictionary, in the wrong hands, can make many an Erlanger curse your
name.

On Oct 28, 2009, at 6:46 AM, Ngoc Dao wrote:

> Hi,
>
> Web frameworks are normally designed as layers (web server ->
> middleware -> front controller -> controller -> action -> view ->
> etc.). Data needs to be passed from one layer to another. There are 2
> ways to pass:
> 1. Proplist (environment variables)
> 2. Process dictionary
>
> The 2nd way:
> * Is Simple and natural in Erlang because normally one HTTP request is
> processed by one process.
> * Makes application code which uses the framework appear to be clean,
> because application developer does not have to manually pass an ugly
> proplist arround and arround.
>
> I want to ask about the (memory, CPU etc.) overhead of process
> dictionary, compared to proplist. Which way should be used in a web
> framework?
>
> Thanks.
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>



--
Jayson Vantuyl
kagato@souja.net






________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Post received from mailinglist
View user's profile Send private message
steved
Posted: Thu Oct 29, 2009 9:14 pm Reply with quote
User Joined: 29 Apr 2008 Posts: 78
On Oct 29, 6:39
View user's profile Send private message
nem
Posted: Fri Oct 30, 2009 12:36 am Reply with quote
User Joined: 29 Nov 2007 Posts: 25
Steve Davis <steven.charles.davis@gmail.com> writes:

> On Oct 29, 6:39 am, Geoff Cant <n...@erlang.geek.nz> wrote:
>
>> Good erlang code does not use the process dictionary.
>
> Note that both gen_server and wx libraries make use of the PD.
>

I think you'll find that gen_server makes almost no use of the process
dictionary. The gen_server code itself makes only one reference to the
process dictionary - to pass the pid of the parent process between the
proc_lib:init stage and the gen_server:enter_loop stage through
arbitrary intervening user code.

proc_lib only uses the process dictionary to store the initial_call and
parent pids of the process. The initial_call is only used in exit reports
and the ancestor/parent pid information is used mainly in exit reports,
though also occasionally by appmon to draw the process ancestry tree and
httpc_manager to implement the is_inets_manager() function.

I don't think the minimal use of the process dictionary in either of
these cases undermines the case that good erlang code does not use the
process dictionary. Occasionally you might have to, to work around
historic code that you can't refactor for backwards compatibility
reasons, or for some particular debugging cases. But that doesn't fall
into my definition of good - just the best possible given the
constraints. New erlang code should strive to avoid the process
dictionary if at all possible.


In the case of 'wx', the process dictionary is used to pass around a
#wx_env{} structure - I'm not quite sure why this wasn't just a
parameter instead. Maybe there's something else (like port ownership?)
that makes tying the structure to the process in the process dict make
sense? I'm kinda curious about this one - if there's a good argument to
be made for using the process dictionary, I'll amend or retract my
anti-process-dictionary bigotry Smile

Cheers,
--
Geoff Cant


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Post received from mailinglist
View user's profile Send private message
wuji
Posted: Mon Sep 17, 2012 7:26 am Reply with quote
User Joined: 10 Aug 2012 Posts: 654
is too afraid to borrow the money," says Chai Ling, Ling, cheap replica designer *beep* Ling, "because she has no idea how she could pay
back." Nor does she have any guarantee the government won't won't [h4]jordan 11[/h4] won't ask for more money in the future. "That is
psychological pressure she is under," says Chai Ling. "It becomes becomes jordan concord becomes a money making operation for the government."Cao told ABC
she very much wanted to keep her baby, but she she cheap jordan shoes she was unsure of what do to. For Cao, waiting
the Saturday deadline is torture, but every moment is also also [h3]jordan concord[/h3] also precious for the expectant mother.Obama Defends Immigrant Deportation Rules
as PoliticalThe President Announces a Change Likely to Please Hispanic Hispanic cheap replica designer *beep* Hispanic VotersBy MATT NEGRIN AND PIERRE THOMASJune 15, 2012 President
View user's profile Send private message

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum