4 ms·

just a guess, afaik syscalls for reads and writes get buffer as a pointer, and java have GC, so if thread gets interrupted, there could happen GC cycle and memo

just a guess, afaik syscalls for reads and writes get buffer as a pointer, and java have GC, so if thread gets interrupted, there could happen GC cycle and memory could be moved to different location, so read would write to outdated memory location potentially causing memory corruption. (I didn't check code, but I bet canceling happens before suspending thread) Could be similar why rust have Pin macros.

layer8 4y ago
You can be 100% sure the internal I/O buffers are pinned in Java’s implementation, and you seem to have a misconception about the Java-specific meaning of “thread interrupt” in this context (it has nothing to do with thread context switches).
- Szpadel 4y ago
  Oh sorry, I don't know java well enough, I tried to approximate knowledge from other languages. This was for me only logical reason why you would need to cancel operation here. So this is about interrupt()? so basically canceling thread?
  - vbezhenar 4y ago
    When you call thread.interrupt(), if a target thread sleeps in a blocking I/O call, this blocking call should throw Java exception. If target thread does not sleep in a blocking I/O (or uses some kind of unsupported blocking I/O, e.g. implemented with third-party JNI library), only some internal flag sets and no magic happens. It's pretty simple implementation actually. Thread is not cancelled or corrupted in any way, if you handle this situation, it's perfectly OK to continue execution in this thread. Usually interrupt is used to coordinate termination, indeed, but that's not the only use. So apparently they didn't find a better way to cancel a blocking I/O operation than just to close file handle from the other thread which causes OS to return some kind of error code from blocking call which translates to Java exception in the end.

4 ms·

just a guess, afaik syscalls for reads and writes get buffer as a pointer, and java have GC, so if thread gets interrupted, there could happen GC cycle and memo

by Szpadel 4y ago

layer8 4y ago
You can be 100% sure the internal I/O buffers are pinned in Java’s implementation, and you seem to have a misconception about the Java-specific meaning of “thread interrupt” in this context (it has nothing to do with thread context switches).
- Szpadel 4y ago
  Oh sorry, I don't know java well enough, I tried to approximate knowledge from other languages. This was for me only logical reason why you would need to cancel operation here. So this is about interrupt()? so basically canceling thread?
  - vbezhenar 4y ago
    When you call thread.interrupt(), if a target thread sleeps in a blocking I/O call, this blocking call should throw Java exception. If target thread does not sleep in a blocking I/O (or uses some kind of unsupported blocking I/O, e.g. implemented with third-party JNI library), only some internal flag sets and no magic happens. It's pretty simple implementation actually. Thread is not cancelled or corrupted in any way, if you handle this situation, it's perfectly OK to continue execution in this thread. Usually interrupt is used to coordinate termination, indeed, but that's not the only use. So apparently they didn't find a better way to cancel a blocking I/O operation than just to close file handle from the other thread which causes OS to return some kind of error code from blocking call which translates to Java exception in the end.