Not resuming Virtual Threads?
Johannes Kuhn
info at j-kuhn.de
Mon Jul 6 09:02:23 UTC 2020
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
More information about the loom-dev
mailing list