Thread Locals (was Re: State of Loom)

[Ron Pressler]

I’m not sure I understand. When using virtual threads there is no thread pool. The
carrier threads are not processing any requests — the virtual threads are. 

If you’re talking about monitoring information, then it’s best to emit events with JFR
and process them afterward. The information available to JFR is more precise, and
includes the identity of the carrier thread.

Reflective access (to non-public members) is only allowed into open modules. The 
java.base modules is not open by default. So far, reflective access to java.base has 
been allowed by default, but this is likely to change soon and hacking into the JDK 
will require a command-line flag.

— Ron


On 28 May 2020 at 19:02:36, Alen Vrečko (alen.vrecko at gmail.com) wrote:

I want to display application level request information on status page for each thread in the thread pool. I want to see that Thread #1 is processing request /foo with session bar coming from ip baz on the server status page.

Currently this is a one liner: map.put(Thread.currentThread(), requestInfo) and a one liner to query the info.

With access to carrier thread. I can migrate to loom with a one liner change: map.put(LoomUtil.currentCarrierThread(), requestInfo).

To do it your way. If I understand correctly. I'd need to write a custom scheduler. In order for my http request processor virtual threads  to tell the scheduler the session id it is processing. I need a custom runnable interface that supplies an object for communication and pass it along the call chain or alternatively the virtual request processor threads could have a property for the request info object?

What is the minimum amount of code to get this done without access to carrier thread?

How will you prevent reflective access?

Best regards
Alen

V V čet., 28. maj 2020 ob 18:43 je oseba Ron Pressler <ron.pressler at oracle.com> napisala:
Can you explain your use case? We have some ideas and will make
some suggestions, perhaps encapsulated as a new core libraries construct,
but the more we know about which use-cases cause particular pain, the
better we can address them.

But let me be clear: the carrier will *not* be accessible by reflection. The base 
module will be closed to deep reflection by default before Loom is delivered.

— Ron


On 28 May 2020 at 15:04:19, Alen Vrečko (alen.vrecko at gmail.com) wrote:

Some of us will just use reflection to get the carrier thread.  

When I went trough the production code and made it play nice with loom. In  
most cases I could find nicer alternatives to TL usage. There aren't many  
TLs being used anyway. But in one particular case I just gave up. The  
alternative is rather involved and in my view convoluted. I opted to get  
the carrier thread reference via reflection and used it to make effectively  
a TL. Simple and it got the job done.  

It might be a good compromise. Find alternatives to TLs. But if there are  
no good alternatives, here is a reference to carrier tread, use it at your  
own risk.  

Alen