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