eclipse-vertx / eclipse-vertx/vert.x

VirtualThread(s) context lookup relies on ThreadLocal(s)

Open
#5,817 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.