Netty Support / VirtualThread Selector#select Issue

[Johannes Schüth]

Hello Alan,

yes - there is one eventloop per thread. That's the default behavior for
Netty. Your feedback gave me some clues on how to adapt the implementation.
Using a single selector with multiple threads makes more sense.
I'm not sure why Netty is using a different approach. Maybe this is done
this way to avoid synchronization on selection key operations (which are
not thread safe).

Johannes


Am Mo., 25. Okt. 2021 um 10:22 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 25/10/2021 06:02, Johannes Schüth wrote:
> > Hello,
> >
> > I started some experiments on how to add Loom VirtualThread support to
> > Netty.
> >
> > During my tests I noticed that Netty was no longer able to handle
> requests
> > when using 500+ virtual threads for its reactor pool.
> >
> > I created a dedicated test without Netty to replicate this issue and
> found
> > that the JVM would not run / start a new virtual thread if 400+ previous
> > threads were calling new `Selector().select().`
> > I'm not yet sure why this is the case. The thread dump shows all threads
> as
> > 'Running'.
> >
> There are cases where the VM cannot suspend a virtual thread, we say
> that the thread is "pinned". One scenario (that we expect will go away
> in the long term) is when a virtual thread is holding a monitor.
> Blocking selection operations are one of these cases. Selector is
> specified to synchronize on the Selector object and can't be changed for
> compatibility reasons. So the summary that invoking blocking selection
> operations on a virtual thread will pin the thread for the duration of
> the selection operation. This means the underlying thread is not
> released to do other work. To compensate, parallelism will increase for
> the duration of the selection operations so you will see the number of
> carrier threads increase up to a limit (default is 256 but can be
> configured).
>
> That said, I'm a bit surprised that you have a Selector per thread. That
> seems an architectural mismatch. Do you have an event loop per thread or
> how does this arise?
>
> -Alan.
>