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

[Jaikiran Pai]

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

>> Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).
>
>> Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).
> 
> Right, there has been quite a bit of back and forth on this. The channel state needs to checked before "beginning" the I/O operation. If asynchronously closed while in the block then the more specific AsynchronousCloseException will be thrown.

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.

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

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