[erlang-questions] the supervisor_bridge behaviour
Thu May 7 14:04:16 CEST 2009
On Thu, May 7, 2009 at 11:37 AM, Gamoto <> wrote:
> 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 ?
Actually, there is no "supported" OTP behaviour to allows easy writing
of stuff like TCP servers, in the way that feels more or less
> 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 ?
I think what you're encountering is what most Network programmers new
to Erlang ask: How do you create Networked Servers using the OTP
principles/behaviours? The key to this is actually that the OTP
principles basically encourage Asynchronity vs Synchronity, which the
gen_tcp class of functionality are synchronous in operation.
That said, there is a recipe on trapexit that shows how to build an
Asynchronous TCP Server using OTP gen_server behaviour, which I think
you may at least want to take a peek at:
I've used this quite extensively, and tried to codify a reusable
behaviour to make it easier to use.
The behaviour code is at:
Two use cases of this behaviour are at:
Use at your own peril ;)
Hope this helps in someway.
> The documentation on internet is very limited on this subject ...
> erlang-questions mailing list
More information about the erlang-questions