Gen_server and multiple processes

hfventer hfventer@REDACTED
Fri Dec 20 08:23:08 CET 2002

Thanks for all the advice so far

The system we have at the moment looks like this:
We have several connections (TCP, but from different subsystem so they
don't all speak the same protocol)  The message is sent to the
appropriate translator to translate if from its native format to our
internal representation of the data.  This representation is then sent
off to be processed.  Once processing is finished a response is returned
on the same communication medium that it came in on.
With the curent gen_server implelentation (that works fine btw) there is
a huge bottleneck, because the next message does not even start
processing before the previous one hasn't completely finished its round
trip.  Obviously this limmits the thoroughput.

Our gen_server is essentially stateless.  It recieves a message to do
something with and sends a response.  If I understand most of the advice
correctly a better way of doing things would be something like the
Once a message is received it spawns a separate message_hanlder thread.
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.  Once the translation is done, the
correct response is sent back to the original worker thread.  This
should free up the connection server to handle as many connections as
the node has memory for and allow the translator to do its job as fast
as it has processors to do it with.
Would the list of spawned processes (workers or message_handlers)
constitute the state of the gen_server now, or would that stil 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?)

This design patters is something that repeats several times in our
system.  Is it possible to easily create our own behavior to make life
easier for some of the newer programmers on the project?

Thanks to every one for your sage advice.


More information about the erlang-questions mailing list