3

I have a parent which when it starts, kicks off a thread that creates an instance of TCP Server that listens on port X. After this, the parent starts forking off child processes (which do few things and exit). Note that these child processes inherit fds from parent and hence end up listening on port X.

The parent program has a handler for requests coming in on port X but the child process has no such handler (it is a os.execv()-ed C++ program)

I know that child process could close all fds, in which case the above situation will not arise. What happens to a incoming request on port X? How is it processed?

Here's what i have observed so far... The tcp request handler in the parents executes commands.getstatusoutput(..) when it receives a request. Most of the times, it behaves as expected (or the way i expected) - execution of the above command without any errors ...but occasionally i get

File "/home/y/lib/python2.7/commands.py", line 61, in getstatusoutput
    sts = pipe.close()
IOError: [Errno 10] No child processes
harish
  • 109
  • 2
  • 6
  • This covers some of the same ground as http://stackoverflow.com/questions/670891/is-there-a-way-for-multiple-processes-to-share-a-listening-socket (not python specific) – Ian Clelland Feb 03 '12 at 18:39

1 Answers1

12

At the operating-system level, there shouldn't be any problem with this. This is essentially the way that pre-forked servers work:

  1. Create socket in main thread
  2. Bind the socket to an address
  3. Call listen() to put the socket into listen mode -- at this point, any connection requests will be accepted and queued by the OS
  4. Fork a bunch of children, each of which inherits the open socket
  5. Then the child processes each call accept(), which blocks until there is a connection for them to handle.

If a child chooses not to call accept() on the listening socket, (as your exec'ed proccess won't) then there shouldn't be any issues for that process, or for the ones who are still accepting connections.

The only complication that I can see is that the socket can't be closed -- in order for the operating system to actually close it, all processes with a reference to it have to call close() on it, bringing its open descriptor count down to zero.

It is probably best, in your case, if that behaviour is interfering with the rest of your application, to close the listening socket in the child -- after you fork, but before you call exec.

Ian Clelland
  • 43,011
  • 8
  • 86
  • 87