Not resuming Virtual Threads?

[Ron Pressler]

Ah, so one thing we are considering is not exactly this, but rather

    boolean isScheduledBy(Executor scheduler)

which might be more general as well as more stable. After all,
there could be situations where the carrier thread changes between
the time you query and the time you want to make use of the
information.

One possible use for this is for UI. AWT could expose a thread scheduler
that schedules virtual threads onto the UI thread. Such a method would
allow enforcing that certain UI operations are done either on the UI
thread or on virtual threads scheduled by the UI scheduler.

— Ron


On 5 July 2020 at 20:12:08, Johannes Kuhn (info at j-kuhn.de) wrote:

Thanks Alan & Ron,  

your answers gave me much insight and food for thoughts.  

When I did look into the claim that there isn't an API to get a  
reference to the default scheduler, I realized that this is probably one  
of the reasons why you can't query the carrier thread.  

Now a new question appeared: Why would I need to know the carrier thread?  
There are a few reasons for it - mostly around native calls / thread  
confinement.  

I suspect that most requirements can be satisfied by asking if a  
particular Thread is the carrier Thread.  
Basically adding the following method to java.lang.Thread:  

    public boolean isCurrentCarrier() {  
        return this == currentCarrierThread();  
    }  

WDYT?  

- Johannes  

On 03-Jul-20 20:53, Alan Bateman wrote:  
> On 03/07/2020 19:25, Johannes Kuhn wrote:  
>> Hi Ron,  
>>  
>> It's sad to hear that Continuations will not be exposed, at least not  
>> at first.  
>>  
>> But it does not solve or hide that issue.  
>>  
>> Your Argument is only valid if every submitted Runnable to an  
>> Executor is eventually called.  
>> If this is not the case, then you have a bug in the Scheduler - at  
>> least if I understood you correctly.  
>>  
>> The default implementation of the Scheduler is a ForkJoinPool, which  
>> comes with a shutdown() method.  
>>  
>> I'm probably missing a big chunk of stuff here. It looks for me, that  
>> by shutting down the executor, you basically cancel all virtual  
>> threads that are currently yielding.  
>> How are their held locks released? (Compare with Thread.terminate())  
>>  
>> In the example at [1], the finally block is never executed. You might  
>> argument that this is a constructed example, and it is.  
>> Still not sure if I want to debug something like that in production.  
> There isn't an API to get a reference to the default scheduler so it  
> should never be shutdown.  
>  
> Bring your own scheduler comes with the responsibility of using it  
> correctly. In your example you are shutting it down mid-flight so none  
> of the threads created to use that scheduler can continue. If someone  
> does that then I agree it might be hard to debug but there is only so  
> much we can do to identify bugging code.  
>  
> -Alan