gen_tcp:controlling_process

Joakim G. jocke@REDACTED
Sun Mar 2 20:24:07 CET 2003


martin j logan wrote:

>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.
>>> 
>>>
>>>      
>>>
>>    
>>
>
>  
>





More information about the erlang-questions mailing list