Yes, I think we're all on the same page now. > So, can we please have a realistic plan to review each change from 4b82e6a, > proposing realistic solution to any issues found?
The goal of 4b82e6a, if I understand correctly, was to avoid passing around stream implementations that override finalize(), for GC performance reasons. Getting threads to interrupt more promptly than before is a "nice-to-have", but really a separate enhancement that can be postponed. With this in mind, there is a solution which achieves what 4b82e6a intended to achieve (dropping finalize()), without changing interrupt-related behavior: Wrap the NIO streams in new InputStream/OutputStream classes, which delegate to them but which catch and retry on ClosedByInterruptException. Then use these classes in all places where explicit interrupt handling has not been deemed to be safe. (See also https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html for the equivalent problem in the UNIX world. Retrying on interrupt is the common solution.) > Leaving an interrupt flag on is just akin to leaving a message in the error > log. Not stopping == ignoring Adding one note here--this is not quite true. A long-running client process is typically doing a series of expensive operations in a loop, e.g. indexing 4000 Java files. Each individual I/O operation will only take a few milliseconds. To support interruptions, the client code will check the thread's interrupt bit once before indexing a new file, and abort the operation if the interrupt bit is set. It is perfectly reasonable to require each individual I/O operation to complete, as long as the thread interrupt bit is checked every now and then. [ Full content available at: https://github.com/apache/incubator-netbeans/pull/854 ] This message was relayed via gitbox.apache.org for [email protected]
