The thread launched in JDIConnection.readRemoteInput() never terminates.
If JDIConnection is repeatedly created, started, and closed -- as in a test, or a long running user session -- the process will lockup, out of threads.
The read is from InputStream (usually System.in) and it is a well known problem that there is no general way to interrupt InputStream.read(..), nor a specific way to interrupt System.in. A polling approach could be used, with possible performance implications:
read(buf, 0, inputStream.available())
Or maybe a hybrid approach: long poll and if any input is detected (rare in practice) switch to the current approach.
Assigned to Jan for evaluation, may assign back.
If JDIConnection is repeatedly created, started, and closed -- as in a test, or a long running user session -- the process will lockup, out of threads.
The read is from InputStream (usually System.in) and it is a well known problem that there is no general way to interrupt InputStream.read(..), nor a specific way to interrupt System.in. A polling approach could be used, with possible performance implications:
read(buf, 0, inputStream.available())
Or maybe a hybrid approach: long poll and if any input is detected (rare in practice) switch to the current approach.
Assigned to Jan for evaluation, may assign back.
- relates to
-
JDK-8163250 JShell tests: jdk/jshell tests fail intermittently while cleaning up threads after test
-
- Closed
-