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