RFR: 8329190: (ch) DatagramChannel.receive should throw ClosedChannelException when called on closed channel

Jaikiran Pai jpai at openjdk.org
Tue Apr 16 13:54:02 UTC 2024


On Tue, 16 Apr 2024 13:46:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.
>> 
>> I found it a bit odd that the existing calls to `ensureOpen()` are being invoked with a `stateLock` which as per its comment states that it is to be used for checking the `state` field, whereas the `ensureOpen()` itself just checks a separate `closed` field which is volatile.
>
>> Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.
> 
> No, that would lead to contention when doing non-blocking I/O. The cases where you see ensureOpen called while holding the stateLock are blocking I/O ops or non-I/O ops that require more complex coordination with close.

OK, thank you Alan for that detail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567403444


More information about the nio-dev mailing list