回复: 回复: 回复: 回复: Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)

[kalinshi(施慧)]

Hook solution can solve problems like passing resource/context to virtual thread from carrier thread.
If resource/context is only needed conditionally, this effort seems not flexible.

Anyway we can find other programmatic ways to access shared resources on  physical thread.

Regards
Hui

发件人: Alan Bateman <Alan.Bateman at oracle.com>
发送时间: 2020年11月12日 19:45
收件人: kalinshi(施慧) <kalinshi at tencent.com>; loom-dev at openjdk.java.net
主题: Re: 回复: 回复: 回复: Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)

On 12/11/2020 10:55, kalinshi(施慧) wrote:

Thank! I checked early discussion and the situation is quite same with us.

There are JLA.getCarrierThreadLocal/setCarrierThreadLocal interfaces. They can be access with --add-exports options and access carrier thread’s thread locals..
Will loom keep these interfaces?
It's way too fragile to depend on this as they may change or be removed at any time.

If I understand your mail correctly then I think you are looking for something like this:

    class Context {
        static final Map<Thread, Context> map = new ConcurrentHashMap<>();
        static Context get() {
            Thread thread = Thread.currentThread();
            return map.computeIfAbsent(thread, k -> new Context());
        }
        void share(Thread thread) {
            map.put(thread, this);
        }
        void unshare(Thread thread) {
            map.remove(thread);
        }
    }

    // custom scheduler with one underlying carrier thread

    ExecutorService pool = Executors.newFixedThreadPool(1);

    Executor scheduler = task -> {
        Thread vthread = ((Thread.VirtualThreadTask) task).thread();
        pool.execute(() -> {
            Context ctxt = Context.get();
            ctxt.share(vthread);
            try {
                task.run();
            } finally {
                ctxt.unshare(vthread);
            }
        });
    };

This uses the "hooks" I mentioned in the previous mail to run code in the context of the carrier thread before/after the virtual thread task runs. In this case, it "shares" a Context object owned by the carrier thread so that it is accessible to the virtual thread. Does this help with your use-case?

-Alan