Details
-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b100
-
generic
-
generic
-
Verified
Description
Looking at UNIXProcess.java.linux, there are a number of possible improvements:
The "process reaper" thread should run in a thread pool to save on
thread creation in case of repeated process creation. Its stack size
should be small.
If the process reaper thread throws a non-IOException (e.g. OOME)
the thread creating the subprocess will hang,
waiting for a signal from the reaper thread.
The JDK knows when the subprocess terminates.
At that time, we cannot yet close the streams,
because there may still be unread buffered data, but...
the file descriptors underlying the subprocess streams
can be drained, then closed, and the drained bytes can
be added to the internal buffer. This will solve most cases
of (pandemic) poor file stream hygiene leading to
file descriptor exhaustion or simply poor performance.
The "process reaper" thread should run in a thread pool to save on
thread creation in case of repeated process creation. Its stack size
should be small.
If the process reaper thread throws a non-IOException (e.g. OOME)
the thread creating the subprocess will hang,
waiting for a signal from the reaper thread.
The JDK knows when the subprocess terminates.
At that time, we cannot yet close the streams,
because there may still be unread buffered data, but...
the file descriptors underlying the subprocess streams
can be drained, then closed, and the drained bytes can
be added to the internal buffer. This will solve most cases
of (pandemic) poor file stream hygiene leading to
file descriptor exhaustion or simply poor performance.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-