Chris Pressey <>
Sat Mar 1 05:43:56 CET 2003

On Fri, 28 Feb 2003 12:15:35 -0000
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.
> 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

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)


More information about the erlang-questions mailing list