RFR: Support yield on virtual thread on EPollSelector select() [v2]

[joeyleeeeeee97]

On Thu, 28 Apr 2022 08:20:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Selection operations are specified to synchronize on the Selector so we can't change the locking without incompatible changes to the specification. So yes, selection operation on a virtual threads pin the carrier. It is something that can be re-examined once restriction on Java monitors is addressed.
>
>> @AlanBateman , Thanks for the tip.
>> Does loom consider providing the ability to customize the 'Poller' threads? For example Netty is using [native implementation](https://netty.io/wiki/native-transports.html) .
>> If loom provides the ability for users to decide where to register blocking operation and how to cooperate with scheduler, frameworks developers could build up their `IO Poller`.
>> For example if loom could opens ability to register blocking event to Poller, and let user start their customized poller as IO mutiplexer.
> 
> Integration at that level is highly problematic because it is platform specific and FileDescriptor internals cannot be exposed. This means the integration point for frameworks like this is LockSupport.park/unpark. They do their own equivalent of registering for I/O events, use LockSupport.park to park the virtual thread, and then do the wakeup with unpark.

@AlanBateman . Yes, this patch could be implemented outside the JDK(by framework developers)..

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

PR: https://git.openjdk.java.net/loom/pull/166