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

[Alan Bateman]

On Thu, 28 Apr 2022 05:16:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> joeyleeeeeee97 has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Support yield on virtual thread on EPollSelector select()
>
> 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.

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

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