Not resuming Virtual Threads?

[Johannes Kuhn]

On 06-Jul-20 0:02, Ron Pressler wrote:
> 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.

Good point. Well, the magic of multi-thread programming in a single thread.
I noticed that some internal APIs use currentCarrierThread() - is there 
a set of "safe" operations that could be done and not fear that the 
thread will yield?

>
> 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
>
For me, the EDT is a stand in for other similar things - native or not.
AWT has the benefit that it is included in the JDK and most people are 
somewhat familiar with it.
I don't say AWT should use Virtual Threads for dispatch - but a library 
similar to AWT may decide to do so.

You can easily create an Executor to execute things on the EDT today 
with `Executor e = java.awt.EventQueue::invokeLater`.
Problem here is the identity of the lambda (that is explicitly NOT 
specified).

I did take a look at `EventQueue.isDispatchThread()` - in the end it 
does something like `return Thread.currentThread() == <expression that 
returns the EDT>`.
So my approach was to make it possible to change that behavior - if the 
library (in this case AWT) desires to do so.

Leads to the question if this would break some of the symmetry with 
`EventQueue.invokeLater()`. I don't really know. Have to think about it 
more.

- Johannes