3 ms·
The problem with thread locals is that you need to copy the value into each platform thread. And the expectation of virtual threads is that any platform thread
by vips7L 2y ago
The problem with thread locals is that you need to copy the value into each platform thread. And the expectation of virtual threads is that any platform thread from the pool would end up running them.
This is super applicable to any system, enterprise or not. If the web framework is running on virtual threads as soon as you query the database your virtual thread will be parked and then another platform thread could potentially pick it up finish running it. Managing thread locals in this situation would be impossible, but you still need some mechanism to manage the global context. It’s really nothing to do with data volume.
- Pet_Ant 2y ago> If the web framework So it's applicable to those writing the framework, not those using it.
- vips7L 2y agoThat absolutely isn't true at all. There's plenty of contextual information you might want to have saved in a scoped value that are currently saved in thread locals. The application I build currently is multi-tenanted. We store the current tenant, the current user, and other data in thread locals. If we were to switch to virtual threads, they would have to be changed to scoped values.
- adrianmsmith 2y agoThreadLocal in Java understands the new lightweight "virtual" threads. If you write into a ThreadLocal, when you read it out on the same virtual thread (even if it's scheduled to a different platform thread) you'll get the same value back.