eclipse-vertx / eclipse-vertx/vert.x
VirtualThread(s) context lookup relies on ThreadLocal(s)
- Dominant language
- Java
- Stars
- 14.7k
- Forks
- 2.1k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 27
Description
### Version
latest 5.x and 4.x
### Context
https://github.com/eclipse-vertx/vert.x/blob/master/vertx-core/src/main/java/io/vertx/core/impl/VertxImpl.java#L101-L104 shows that while creating virtual threads from other virtual threads we would use ThreadLocal(s) - which is a bad pattern due to the heavyweight nature of TL w Loom.
See https://github.com/netty/netty/issues/13191 and https://github.com/quarkusio/quarkus/issues/39696
There are few option(s) here:
- using CHM (which is not great I know) but it requires been in control of the whole VT lifecycle to be able to remove the VT from the CHM on completion
- using ScopedValue (in some creative ways e.g. https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/7b9b122572676c65e51aa40ce5afbdf1fbcb7afb/core/src/main/java/io/netty/loom/EventLoopScheduler.java#L93) - but similarly requires to be in control of the VT lifecycle
IDK how to better fix it, since it's purpose is to propagate the context (see https://github.com/eclipse-vertx/vert.x/blob/7b1c42e4f04306638727757ad5c68cea5b17977f/vertx-core/src/main/java/io/vertx/core/impl/VertxImpl.java#L481), but we can think of a better and more performant way for sure.
### Steps to reproduce
_No response_
### Do you have a reproducer?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.