Virtual Threads and Handling of Interrupted IO Exception in Socket Classes

[Alan Bateman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250212/4fc657a6/attachment-0001.htm>