gen_tcp:controlling_process
Chris Pressey
cpressey@REDACTED
Sat Mar 1 05:43:56 CET 2003
On Fri, 28 Feb 2003 12:15:35 -0000
Sean Hinde <Sean.Hinde@REDACTED> 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
OK, I added connection capping to my version, the results can be seen at
http://kallisti.mine.nu/projects/ce-2003.0228/src/ce_socket.erl
With it, the complexity *does* increase - I'm beginning to see why Joe's
looks the way it does.
Because the accept call waits until a connection comes in, it has to be
handled asynchronously if you want to be able to handle messages (like
{'EXIT',Pid,Reason} to count how many sockets are currently connected)
while waiting.
So you need another process. I did it kind of backwards compared to
Sean's description - the main loop spawns an asynchronous accept process
each time it starts waiting (and kills it when it realizes it's run out of
connections, so there's probably a tiny race condition there... I'll work
on it not starting it in the first place, tomorrow)
-Chris
More information about the erlang-questions
mailing list