Update how unstarted event loop v threads are created (Fixes #49) #50
Conversation
| return runnable -> NettyScheduler.newEventLoopScheduledThread(() -> ScopedValue | ||
| .where(CURRENT_SCHEDULER, new SchedulingContext(Thread.currentThread().threadId(), sharedRef)) | ||
| .run(runnable), sharedRef); | ||
| var unstartedBuilder = Thread.ofVirtual(); |
There was a problem hiding this comment.
@AlanBateman I would have expected this new method to be static in Thread.OfVirtual.
Second: do you think is ok to make users able to set the preferred carrier?
e.g. see the comment below
There was a problem hiding this comment.
If you asking why the 3-arg unstarted method is an instance method then it needs to be in order to pick up other properties set via other builder methods. The overload is a restricted method in the prototype to deter casual use.
There was a problem hiding this comment.
Thanks for answering Alan!
And in relation to setting the preferred carrier instead: do we really want users to be able to do that?
I would have expected this argument to be useful for pollers - whilst users which implement their custom scheduler could enforce it by other means e.g. like I am doing in the Netty scheduler, dynamically
This pull request refactors how virtual threads are created and scheduled in the Netty Loom integration. The main improvement is a more robust and leak-resistant approach to virtual thread scheduling, ensuring that threads are properly offloaded when a scheduler is no longer available. The code is also simplified by removing an unnecessary helper method.
Improvements to virtual thread scheduling:
newEventLoopSchedulerFactoryinEventLoopScheduler.javato use aThread.ofVirtual().unstarted()builder for creating virtual threads, and introduced arunWithContexthelper to ensure the correct scheduling context is set. This change avoids enforcing a preferred carrier, which helps prevent thread leaks when schedulers are shut down.Codebase simplification:
newEventLoopScheduledThreadhelper method fromNettyScheduler.java, as thread creation is now handled directly in the scheduler factory.