Gen_server and multiple processes

Sean Hinde Sean.Hinde@REDACTED
Fri Dec 20 10:31:13 CET 2002


> >>Yes. You have a message server that receives all messages 
> and spawns a 
> >>new server (Let us call it a message handler)
> >>
> >Just to check, you mean to actually spawn a new OTP 
> gen_server?  Is this
> >not slow since it has quite a bit of overhead.
> >The idea we had was to have one gen_server that spawns its own worker
> >threads in the handle_call.
> >
> I would first try with a dynamic child in a gen_server. Yes, 
> you do have 
> overheads, but at the same time, you have supervision, control, and 
> uniformity. 
> 

Or if you really don't think you need a full blown gen_server in each case,
you could create your short lived processes using proc_lib:spawn_link().
This provides nice crash reports if the worker crashes but is otherwise a
bit less overhead than using dynamic children/gen_servers.

For example our usual tcp server pattern has a new gen_server created for
each new socket conection but each new call creates a proc_lib:spawn_link().
I tend to keep an ets table holding the worker pids as the gen_server state,
and like to hold at least the transactionid/header information from the
incoming packet with the Pid so that if the worker crashes I can retrieve
this and return an appropriate error response to the client.

Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.




More information about the erlang-questions mailing list