[Patch] PR 31228, Fix close-on-exec race.

Andrew Haley aph@redhat.com
Wed Mar 21 10:10:00 GMT 2007


Tom Tromey writes:
 > >>>>> "David" == David Daney <ddaney@avtrex.com> writes:
 > 
 > David> Make the accept non-blocking, and do a select/poll on the
 > David> ServerSocket. That way the accept would never block and you could use
 > David> a mutex.
 > 
 > Yeah.  I hadn't thought of the accept case, thanks.
 > 
 > David> This makes me think that ld.so is probably broken also.  When we do
 > David> dlopen ld.so opens the library file and does several mmaps before
 > David> closing the file descriptor.  These could leak out as well.
 > 
 > Not to mention other places that libc may create fds.

And native code such as GUI toolkits that we don't control.  Maybe
they mark their file descriptors FD_CLOEXEC, maybe they don't.

 > On some platforms fdwalk(3) can be used to make this close loop more
 > efficient.  There's also closefrom(3).  Linux doesn't seem to have
 > either of these, but Solaris does.

Closing all file descriptors on exec() is a normal idiom.  Only
measurement will tell us whether this is a big time hog, and we
shouldn't do any optimization until we know it's needed.

Experience has shown that we (well me, anyway) are almost always wrong
about where the time goes.

Andrew.



More information about the Java-patches mailing list