State of Loom

[Alan Bateman]

On 20/05/2020 16:55, Mike Rettig wrote:
> The UI code I've seen will have problems with out of order executions.
>
> Consider this psuedocode and how it could execute with loom vs a
> single threaded executor:
>
> ui.execute(()->{
>    log.info("disabling user input");
>    lockUserInput("Please Wait. Calculating totals");
> });
>
> final Totals totals = calculations();
>
> ui.execute(()->{
>     refresh(totals);
>     unlockUserInput();
> });
>
> Loom will ensure the UI is reponsive when blocked, but at the
> complexity of out of order executions. In my experience, any design
> that has the potential to reorder changes to some shared state is best
> avoided.  IMO, backing virtual threads with a single thread is an
> anti-pattern. The thread is still susceptible to pinning, but now out
> of order executions are added to the mix. The code needs to be written
> as if it is multi-threaded, but at runtime it doesn't get the benefits
> of parallel execution.
I realize this is pseudocode but I'm wondering whether to read 
"ui.execute(...)" as invokeLater or invokeAndWait or something else?

As Ron had as an example, you could specify EventQueue::invokeLater as 
the scheduler to enlist the AWT EventQueue dispatch thread as a carrier 
thread but it usefulness might be limited. Code executed by a virtual 
thread mounted on the AWT EventQueue dispatch thread would execute in 
the context of a virtual thread and EventQueue.isDispatchThread() would 
return false.

-Alan