[erlang-questions] Design question
Tue May 1 20:50:26 CEST 2007
On 5/1/07, Jim Menard <jim.menard@REDACTED> wrote:
> I'm a newcomer to Erlang, working my way through Programming Erlang.
> To help me learn, I'm porting a small Web application to
> Erlang/Erlyweb. Since I am new to Erlang, I have a design question.
> In this app, calendar objects are created on the fly, one for each set
> of users. The calendars will only live for a short while (ten minutes
> after the last recorded use, which gets refreshed if somebody uses it
> in that time). The first request for calendar X will create a calendar
> with that id.
> My first thought is "one spawned process per calendar". Does that make
> sense? If so, should I use the process dictionary in the main process
> to map a calendar's identifier to the Pid for that calendar's process?
Since I don't know what the calendar process is supposed to do it is a
little difficult to say if it is the correct way or not. But generally in Erlang
it is the correct answer.
I think it would be better to use an ETS table instead of the process
> I'm thinking that each calendar process will send a message back to
> the main process when it is going to kill itself so the main process
> can erase that entry from the process dictionary.
If You create a link from the main process to the calendar processes
the main process will receive a message whenever a calendar process
terminates, without the calendar process having to send a message on its own.
> Another question: if I do use the process dictionary to store the
> calendar id-to-Pid mapping, isn't that a possible multi-threading
> danger zone? If two users ask to create the same calendar at the same
> time, I have a possible race condition. This tells me that what I'm
> thinking of doing is very, very, wrong. Any suggestions?
Who is it that create the calendar id-to-pid mapping? The main process?
In that case it is no problem since the main process handles one request
at a time.
If it is the calendar process that registers the id-to-pid it would be
More information about the erlang-questions