I have the following situation (pseudocode):
function f:
pid = fork()
if pid == 0:
exec to another long-running executable (no communication needed to that process)
else:
return "something"
f
is exposed over a XmlRpc++ server. Whe开发者_开发问答n the function is called over XML-RPC, the parent process prints "done closing socket" after the function returned "something". But the XML-RPC client hangs as long as the child process is still running. When I kill the child process, the XML-RPC client correctly finishes the RPC call.
It seems to me that I'm having a problem with fork()
copying socket descriptors to the child process (parent called closesocket
but child still owns a reference -> connection still established). How can I circumvent this?
EDIT: I read about FD_CLOEXEC
already, but can't I force all descriptors to be closed on exec
?
No, you can't force all file descriptors to be closed on exec. You will need to loop over all unwanted file descriptors in the child after the fork()
and close them. Unfortunately, there isn't an easy, portable, way to do that - the usual approach is to use getrlimit()
to get the current value of RLIMIT_NOFILE
and loop from 3 to that number, trying close()
on each candidate.
If you are happy to be Linux-only, you can read the /proc/self/fd/
directory to determine the open file descriptors and close them (except 0, 1 and 2 - which should either be left alone or reopened to /dev/null
).
精彩评论