gen_tcp:controlling_process

[martin j logan]

Jocke, 
    Out of curiosity what method do you prefer to use when writing
something general that you wish a user to be able to extend with
specific functionality? I find callback programming to be the simplest
technique - at least in Erlang. I would be interested in your
opinion/preference - if you have the time and inclination to give it.

Cheers,
Martin 

On Fri, 2003-02-28 at 07:10, Joakim G. wrote:
> I often argue that callback oriented programming is boring. Still I found
> myself writing:
> 
> http://www.gleipnir.com/xmlrpc/unpacked/LATEST/src/tcp_serv.erl
> 
> A good old ad hoc tcp server behaviour. :-)
> 
> Cheers
> /Jocke
> 
> Sean Hinde wrote:
> 
> >>As Martin says "use with care" it is worth pointing out 
> >>another way of doing
> >>this:
> >>
> >>Have a process which owns the listening socket. This will 
> >>spawn a socket
> >>process which will block in accept until a client arrives - 
> >>at which time it
> >>messages back to the listening process to tell it to spawn a new
> >>socket/accepting process.
> >>
> >>This model is widely used but for a very nice example take a 
> >>look at joe's
> >>recent web_server tutorial. http://www.sics.se/~joe
> >>    
> >>
> >
> >Now I just read Chris' post pointing out Joe's comment that this is very
> >complex.. If you study Joes code (always an education) you will eventually
> >see why, but if you don't need to limit the number of connections then my
> >recipe will work OK (you of course do need to handle EXIT messages from the
> >accepting process, which may arrive before or after the accept succeeded)
> >
> >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.
> >  
> >
> 
>