[erlang-questions] the supervisor_bridge behaviour

Bengt Kleberg bengt.kleberg@REDACTED
Thu May 7 13:29:13 CEST 2009


I am sorry that my explanation did not make things clearer.

However, you are correct when you write that you should not use the
supervisor_bridge behavior.

If you have decided not to use a gen_server you can still make a process
part of a supervisor tree. It will be a special process, a user defined
process which comply to the OTP design principles. In that case you need
the proc_lib module (http://erlang.org/doc/man/proc_lib.html). Your own
code will need some callbacks as described in 6.2 Special Processes
(http://erlang.org/doc/design_principles/spec_proc.html).


bengt

On Thu, 2009-05-07 at 12:37 +0200, Gamoto wrote:
> Hi Bengt,
> No it is not clearer !
> 
> I don't have an existing application. I am building it and I don't know which kind of behaviour I must put.
> That would say, I have no reason to use supervisor_bridge ?
> 
> I want to supervise several "client-server" processes, each one specialized for one protocol.
> I use gen_tcp primitives (listen,accept,recv,send,close) , not gen_server.
> 
> I try to explain my structure: you can correct it of course !
> main_supervisor supervises the client-server processes (called SRV later), one for one strategy, behaviour = supervisor
> If one SRV hangs, the other one shall not be disturbed.
> One SRV can receive several connection from several clients. If one socket hangs, the other one shall not be disturbed.
> I suppose that the SRV is also a supervisor of processes.
> SRV manages the listen primitive. For each accept, a process (called P later) is created to manage the recv/send primitives.
> 
> And now I am lost. Behaviour of SRV ? addition or not of an supervisor between SRV and the  P processes ? if yes, behaviour ? why ?
> 
> John
> 
> The documentation on internet is very limited on this subject ...
> 
> 
> 




More information about the erlang-questions mailing list