Thread Locals (was Re: State of Loom)

[Mike Rettig]

On Thu, May 28, 2020 at 1:02 PM Alen Vrečko <alen.vrecko at gmail.com> wrote:

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

Is there any locking to make the map thread safe? You said the map is
queried for status information, so I assume the map needs to be thread
safe. If the map has a lock, then the put could result in the wrong
thread being registered since the currentCarrierThread() method will
give you the active thread, but loom could reschedule the thread if a
lock is encountered during the put operation resulting in a different
carrier thread actually executing the request.

One solution to this is to attach state to the virtual task and allow
the custom scheduler to refresh the state. Though I don't see in the
current api how to attach state to a virtual thread. I do think having
the ability to attach state when creating a virtual thread will help
framework designers deal with the changes to ThreadLocal.

ExecutorService pool = ....;
Executor scheduler = (task) -> {
var vthread = ((Thread.VirtualThreadTask) task);
pool.execute(()->{
   var requestInfo = vThread.attachment();
   map.put(Thread.currentThread(), requestInfo));
    try {
           task.run();
          } finally {
             map.remove(Thread.currentThread());
          }
 });
};

Mike