Hi Karen,
In my opinion, it is recommemded to use O_CLOEXEC flag directly in
open() function than setting it later via fcntl(). And according to the
man page on Solaris and Mac, open() behaves the same on those platforms.
I only find the support platform list for jdk7 at
http://www.oracle.com/technetwork/java/javase/config-417990.html.
Because Linux 2.6.23 was released long ago on Oct 9, 2007, most
platforms should already have the support to O_CLOEXEC flag.
Thanks,
-Dan
On 01/31/2013 07:30 AM, Karen Kinnear wrote:
Dan,
I had a question on this comment.
Should we fix this in hotspot?
So you mention recent Linux open() documentation.
How does this behave on Solaris and Mac? I assume the library code is
shared code across platforms.
Also - what is the oldest Linux we support for JDK8?
thanks,
Karen
On Jan 29, 2013, at 6:55 AM, Alan Bateman wrote:
- I don't think the O_CLOEXEC code is needed in handleOpen, was
this copied from HotSpot?
In the original hotspot code, it has one section to enable the
close-on-exec flag for the new file descriptor as the following.
#ifdef FD_CLOEXEC
{
int flags = ::fcntl(fd, F_GETFD);
if (flags != -1)
::fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
}
#endif
According to the comment, "All file descriptors that are opened in
the JVM and not specifically destined for a subprocess should have
the close-on-exec flag set. If we don't set it, then careless 3rd
party native code might fork and exec without closing all
appropriate file descriptors (e.g. as we do in closeDescriptors in
UNIXProcess.c), and this in turn might:
- cause end-of-file to fail to be detected on some file
descriptors, resulting in mysterious hangs, or
- might cause an fopen in the subprocess to fail on a system
suffering from bug 1085341."
And the recent open() function (since Linux 2.6.23) already has
O_CLOSEXEC flag to enable this flag by default. And it is a
preferred way according to the man page, " Specifying this flag
permits a program to avoid additional fcntl(2) F_SETFD
operations to set the FD_CLOEXEC flag. Addi-tionally, use of this
flag is essential in some multithreaded programs since using a
separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag
does not suffice to avoid race conditions where one thread opens a
file descriptor at the same time as another thread does a
fork(2) plus execve(2).
Additionally, if O_CLOEXEC is not supported, F_DUPFD_CLOEXEC is
preferred than FD_CLOEXEC, which is what hotspot is using right now.
I don't think we need this because the file descriptor will be closed
at exec time anyway (there is logic in Runtime.exec to iterate over
the file descriptors and close them). Also we don't do this in other
areas of the platform where we use open directly.
