Not resuming Virtual Threads?

[Johannes Kuhn]

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