[erlang-questions] Design question

[Jim Menard]

Anders,

On 5/1/07, Anders Nygren <anders.nygren@REDACTED> wrote:
> On 5/1/07, Jim Menard <jim.menard@REDACTED> wrote:
[snip]
> > 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.

Each calendar records time slots coming from each user, and on request
reports back all of the slots from all users back to each user. It's a
temporary shared calendar.

> I think it would be better to use an ETS table instead of the process
> dictionary.

Why do you recommend that? For persistence (in case the main process
dies)? In this application, persistence is not important. If
everything is lost, that's ok. These calendars are throw-away.

[snip]
> 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.

Aah, right. I remember reading that now.
>
> >
> > 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.

Yes, the main process would create them. As a newbie, I had not yet
internalized the serial nature of incoming messages.

(Actually, that's a question I have about Erlang's design: it seems to
me that inboxes are the only place in Erlang's internals that has to
worry about mutex locking, because incoming messages have to be added
to the inbox safely. Am I correct?)

Thanks for your advice.

Jim
-- 
Jim Menard, jimm@REDACTED, jim.menard@REDACTED
http://www.io.com/~jimm/