carrier local

[Alen Vrečko]

Ok, I see, you are saying migrate your code away from using TL Random and
TL Date Formatter.

What would be a replacement for TL Random?

I think carrier locals could work safely if you have a safety mechanism
that guarantees that a carrier locals cannot escape scope. I.e. carrier
local is only accessed/referenced between 2 parks.

To continue your example:

SimpleDateFormat format = carrier.get();
format.format(...); // run by carrier Thread 1
socket.read(...)       // scheduling point, may park
format = carrier.get(); // reacquire - on carrier Thread 2
format.format(...)

Alen

V V pet., 3. apr. 2020 ob 10:56 je oseba Alen Vrečko <alen.vrecko at gmail.com>
napisala:

> 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
>>
>