Virtual Threads and Handling of Interrupted IO Exception in Socket Classes

[Bahaa Zaid]

Thanks for the clarification.

I never got an InterruptedIOException when using platform threads. This was misunderstanding from my side when I read the code of Socket class. So, I think higher level libraries should check for Thread.currentThread().isInterrupted() before assuming a network error. 

Thanks again and sorry for the confusion.

> On 12 Feb 2025, at 7:32 PM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 12/02/2025 17:05, Bahaa Zaid wrote:
>> Hello,
>> 
>> I have a question about handling InterruptedIOException in net Socket classes. All these classes catch the exception and check if the thread is virtual, if so, a SocketException is thrown instead with the message “Closed by interrupt”. My question is why not just throw InterruptedIOException like platform threads? And can the caller depend on this message "Closed by interrupt” to identify an interrupted operations instead of a network error?
>> 
>> This is causing unexpected behavior in some areas. For example, PostgreSQL JDBC Driver is treating an interrupted operation as a network error. This in turn cause the connection pooling library to mark the connection as broken and it disposes it. Can their implementation depend on the exception message? Or in such state, the socket is not reusable anyway?
>> 
> Socket operations are not interruptible in the context of platform threads. InterruptedIOException should never be exposed, are you sure you are getting this exception? (trying to see if we have a bug where this exception is leaking out callers of the Socket methods).
> 
> Socket operations are interruptible in the context of virtual threads. These methods are specified to throw close the Socket and throw SocketException with the interrupt status set. So Socket::isClosed and Thread.currentThread().isInterrupted() will return true.
> 
> -Alan
>