controlling_process and TCP servers

[Chris Pressey]

On Sat, 01 Mar 2003 15:26:10 -0800
Jay Nelson <jay@REDACTED> wrote:

> Sean Hinde wrote:
> 
>  > > 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
> 
> Chris Pressey wrote:
> 
>  > 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.

The URL for my latest version is

http://kallisti.mine.nu/projects/ce-+

(Filename completion: just one of the many Stupid Webserver Tricks I've
implemented :)

I've also imported the library into Jungerl, and I'll probably publish
future snapshots of it from there.

> [...]
> Joe avoids spawn race conditions by maintaining {active,
> false} until the handler is ready to run, so the mailbox of
> messages doesn't get confused between processes and
> he doesn't need to call controlling_process.

According to Martin, this isn't an issue anyway - all tcp messages that
have already been sent are bequeathed to the new process when you call
gen_tcp:controlling_process.

> Chris has a similar approach with the main differences in
> the over-generation of an Accept and the use of gen_tcp:
> controlling_process.

The other thing that controlling_process does is that it changes the owner
of the socket.  If the owner of a socket dies, that socket gets closed
too.  That's the reason I call it twice - once to transfer control from
the Accepter to the main loop, and again to transfer it to the callback
module.  Since my Accepter dies and gets respawned, this stops the socket
from disappearing before it gets to the main loop.

Also, since my Accepter dies, I don't ever link to it, because I don't
want to get the 'EXIT' message, because it's easier to assume in the main
loop that those only come from the callbacks.

It wouldn't be hard to keep the Accepter alive indefinately instead of
continually spawning new ones - send it synchronization messages - but I
wanted to keep the complexity down a bit initially - maybe later.

-Chris