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