File IO and the Swing Event Dispatch Thread

[Dávid Karnok]

Thanks,

I've written Swing apps following the guidelines of doing IO on a
background thread and post back to the EDT. From memory, I encountered a
few uses of isDispatchThread: for example, if not on the EDT, post the work
to the EDT. Another rare example was to fail with an exception if not on
the EDT. Sometimes, the former was created to avoid the exception from the
latter.

As for the File IO, if I open several thousand files with FileInputStream,
each in its own virtual thread, and the reads go slowly, can I possibly end
up with thousands of OS threads? In other terms, would it be better with
virtual threads than doing the same thing today (with JDK 15) and
submitting to a newCachedThreadPool?

Alan Bateman <Alan.Bateman at oracle.com> ezt írta (időpont: 2020. dec. 1., K,
14:14):

> On 01/12/2020 12:59, Dávid Karnok wrote:
> > Hello.
> >
> > I watched the recent interview (
> https://www.youtube.com/watch?v=EDVesJ-yJ6U
> > ) considered the following scenario: in a Swing desktop app, the user
> > clicks a button which then reads through a file, right there in the
> > ActionListener.
> >
> > If I understood the interview correctly, the Event Dispatch Thread won't
> be
> > supporting suspensions so one has to make a custom scheduler that
> delegates
> > back to it, right? Second, I presume async file IO needs OS support (
> > https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html ) thus
> > could/would it work on, let's say Windows, without ending up with
> arbitrary
> > number of blocked OS threads?
> There is work-in-progress that is investigating if it makes sense to use
> the AWT Event Dispatch Thread (EDT) or the Java FX application thread as
> a carrier thread. You can of course create a custom scheduler today with
> `Executor scheduler = EventQueue::invokeLater` but each of the virtual
> threads will have its own identity. Part of the investigation is to see
> is to see if methods such as isDispatchThread should return true when
> the carrier thread is the EDT. It may be the conclusion is that it's not
> worth doing but if you have experience in this area then please share it.
>
> The current support for custom schedulers doesn't have the equivalent of
> ManagedBlocker, which I think is what you are asking. When using the
> default scheduler then the set of carrier threads may temporarily expand
> for these cases.
>
> -Alan
>


-- 
Best regards,
David Karnok