carrier local

[Alen Vrečko]

For my use case with buffers, not a big deal, I'll go with a Buffer Pool
instead of ThreadLocal pool.

My status page use case is solvable with a custom thread pool executor. It
would be just a few lines of code if I had access to carrier local. Now it
will be much more than that. As I want to see what each Thread Pool thread
is doing on app level e.g.

App Worker #1 serving /foo from 192.168.3.2 (Android) sessionId:bar
App Worker #2 copying X from ftp Y sessionId:baz
App Worker #3 idle

I think this is why you are against carrier locals. Pseudo code Example

public void processHttpGet(HttpRequest req, HttpSession session){
   NativeBuffer buf = CARRIER_LOCAL.get();  <--- Carrier Thread 1
   int read = AsyncIo.readFile(req.getParam("file"), buf, ...); <---
Virtual Thread Park
   session.sendResponse(buf); <---- Carrier Thread 2! Bug, escaped scope
}

How would you do Carrier Local Date formatter and Random? This are valid
real world use cases that I think should be supported by Loom.

Alen

V V čet., 2. apr. 2020 ob 21:17 je oseba Alan Bateman <
Alan.Bateman at oracle.com> napisala:

> On 02/04/2020 14:23, Alen Vrečko wrote:
> > Hello, everyone.
> >
> > I have some thread local byte buffers. But now the threads are virtual
> and
> > it defeats the purpose.
> >
> > Shouldn't the ThreadLocal act as carrier local? As ThreadLocal is
> > effectively a private field for VirtualThread thus rendered useless?
> >
> > How do you access carrier thread via the API?
> >
> > I wish to list all the thread pool threads on server status page and have
> > next to them some application level context data. This context is added
> > using thread local. But now it doesn't work.
> Virtual threads support thread locals so they can run existing code. It
> is possible to create virtual threads that don't allow thread locals to
> avoid footprint bloat but you quickly run into issues when you run
> something that expects to be able to set/get locals.
>
> There is no support in the API for accessing the carrier thread's locals
> as it would not be safe to access these locals across scheduling points.
>
> I can't tell from your mail what "doesn't work". Is this something that
> used thread pools and used thread locals to cache something across
> tasks? Are thread locals the right thing for these buffers? If you
> really want to have control over the resources managed by carrier
> threads then it requires using a custom scheduler as that gives you the
> "hooks" to run something before/after the tasks submitted to run the
> virtual thread between scheduling points.
>
> -Alan
>