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.
>
>>
