From: knutaf@...
Date: 2009-06-10T23:35:09+09:00
Subject: Re: inheriting socket in child process on Windows

On Jun 10, 5:06 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> 2009/6/10  <knu...@gmail.com>:
>
>
>
>
>
> > In my Ruby application, I accept TCP connections from several clients.
> > When
> > any client sends a particular command, I want to spawn a child process
> > in
> > place of the parent process that will continue to service the already-
> > open
> > TCP connections without the clients needing to reconnect.
>
> > I originally wrote this code on Linux, and it works in the most
> > obvious way:
>
> > When the command is received, make note of all of the client's file
> > descriptors (IO#fileno). Spawn the child process and communicate the
> > list of
> > file descriptors to it. In the child process, call TCPSocket.for_fd
> > for each
> > file descriptor, and it is ready to read and write data.
>
> I would find this more obvious:
>
> server = TCPServer.new port
>
> while ( client = server.accept )
>   printf "Got client %p\n", client.peeraddr
>
>   fork do
>     client.each do |line|
>       client.printf "ECHO: %p\n", line
>       client.flush
>     end
>
>     client.close_write
>   end
>
>   client.close
> end
>
> > Is there an entirely different
> > approach I should be taking?
>
> I do not know whether you _should_ take this approach but using cygwin
> might ease your pain considerably.  The approach noted above does work
> on cygwin.
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/- Hide quoted text -
>
> - Show quoted text -

True, I did realize after I posted that perhaps my way isn't the "most
obvious." In any case, I'd very much like to avoid requiring cygwin
for this to work. Plus, with cygwin, I would guess my original Linux
approach would probably work without modification.

Finally, after testing it out briefly, I don't think fork will work in
my situation. I didn't give enough context originally, but I'm
spawning the new child process in order for it to be the same process
as the parent, but having picked up any code changes that have been
made. A "live reboot", if you will. Fork doesn't seem to re-interpret
the source.