RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive

[Jaikiran Pai]

On Tue, 18 Jul 2023 14:03:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > On a general note and more out of curiosity, I see that the `DatagramChannelImpl` dishonours the `blocking` mode set by the caller and forces non-blocking when virtual thread is involved and yet at the same time fulfills the contract of `receive()` and `send()` and even `isBlocking()`.
> > Is there a reason we couldn't do the same for platform threads and dishonour the blocking mode and always use non-blocking in these `send()` and `receive()` implementations?
> 
> The blocking mode of the underlying socket is an implementation detail, it has no impact on the SocketChannel's blocking mode or the semantics of any of its methods. If a SocketChannel is in blocking mode and used exclusively by a platform thread then the underlying socket will be in blocking mode to avoid additional syscalls. If the underlying socket were non-blocking then it would require receive+poll+receive rather than a blocking-receive to wait for a datagram.

Thank you Alan for the explanation. That helped.

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

PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1640315153