Gen_server and multiple processes
Francesco Cesarini
francesco@REDACTED
Fri Dec 20 09:04:48 CET 2002
Comments below, but from what I understand, you should spawn one process
for each incoming message. You then use this process to translate,
process, and send the reply back to the client. From what I understand,
you have implemented your translator as a process. Can you strip out the
code and just have a module that can be called? Translating is not a
truly concurrent activity, as you might have many messages from the same
source to translate at the same time. Handling the message is a
concurrent activity, however.
hfventer wrote:
>
>Our gen_server is essentially stateless. It recieves a message to do
>something with and sends a response.
>
This will allow you to spawn a process for every incoming message.
>Once a message is received it spawns a separate message_hanlder thread.
>
Yes. You have a message server that receives all messages and spawns a
new server (Let us call it a message handler) every time one is
received. This server sends back a noreply to the caller, and passes the
From variable from the handle_call(Msg, From, State) callback. The
caller will be suspended waiting for a result.
>This thread sends the message to the appropriate translator. The
>translator spawns a worker thread to do the actual translation and
>immediately sends back a no_reply.
>
No. Implement your translator as a function which is called by the
message handler. There is no need for extra message passing or
processes. If the translator has a state or data, use a public ets table.
> Once the translation is done, the
>correct response is sent back to the original worker thread.
>
Yes, using gen_server:reply(From, Msg), the From coming from your
original request. This is also done from your message handler.
>Would the list of spawned processes (workers or message_handlers)
>constitute the state of the gen_server now, or would that still be
>supperfluous? (maybe for orderly shutdown purposes the list needs to be
>kept? Would this be generaly good design or is there an easier way?)
>
It would be superfluous, as the supervisor would handle the shutting
down. If you have a system restart, I would assume that all the TCP
connections would go down, so there is no need in saving them.
Take a look at the slide show from my presentation at EUC, looking at
the before and after slides of the architecture. THe jabber server had
the same bottleneck as you describe, as every socket pair was one
process, but the rest wasn't. You can see it at
http://www.erlang-consulting.com/euc2001/.
Best of luck,
Francesco
--
http://www.erlang-consulting.com
More information about the erlang-questions
mailing list