8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible

[Chris Hegarty]

Alan,

> On 19 Dec 2019, at 15:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> This is an update to the SelectorProvider implementation with two related parts to it:
> 
> 1. The upcoming replacement of the DatagramSocket and MulticastSocket implementations needs a socket adaptor that is not interruptible. It also needs to be able to create it with built-in selector provider. This part of the changes makes this easy with DefaultSelectorProvider.get().openUninterruptibleDatagramChannel(). The main difference between an interruptible and uninterruptible DatagramChannel is that the hooks for Thread.interrupt aren't setup around blocking operations, instead the uninterruptible case just needs to check for async close at the end of blocking operations.
> 
> 2. The second part is that SelectorProvider is specified to locate the default provider when its "provider" method is first called. The current implementation uses a lock to allow that initialization but it means that the creation of all channels with the static factory methods (the common case) ends up being synchronized. Moving the initialization of the default provider to a holder class allows this lock to be removed.
> 
> The webrev with the changes is here. I've added a test to exercise the (internal) openUninterruptibleDatagramChannel.
> 
> http://cr.openjdk.java.net/~alanb/8236246/webrev/


This seems fine.

There is a lot of duplication between the platform-specific
DefaultSelectorProvider code. Can this be consolidated?

I checked the DatagramChannelImpl changes against what is in the
sandbox branch for the upcoming proposal to replacement of DS & MS [1],
and the code in this webrev seems to logically equivalent.

-Chris.

[1] http://hg.openjdk.java.net/jdk/sandbox/rev/8c724fbaeb99