Native transports, since they can "pin" their carrier, have their life-cycle bound on a carrier(s) - which start, and "own" them.
More, awaking such scheduler(s) requires interacting with the native transport - if pinned/sleeping (usually via eventFd).
For NIO, is much different:
- Netty event loops like locality, even with NIO, because they bring many structures with them, but is NOT a functional requirements, is more an efficiency one
- since JDK +24 NIO selectors doesn't pin anymore, there's no need to selector::wakeup on VT submissions or to check for run q emptiness before selector::select. We can just let it go.
This means the requirements for NIO and native transports and what they can do (or not do) and how much they "limit" a custom scheduler is very different.
And the current implementation is not accounting for that.
Native transports, since they can "pin" their carrier, have their life-cycle bound on a carrier(s) - which start, and "own" them.
More, awaking such scheduler(s) requires interacting with the native transport - if pinned/sleeping (usually via eventFd).
For NIO, is much different:
This means the requirements for NIO and native transports and what they can do (or not do) and how much they "limit" a custom scheduler is very different.
And the current implementation is not accounting for that.