Detecting threading problems faster

[Andy Goryachev]

John:

Can you cite a bug or give an example of such a problem?

During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe.  It is possible that I use the system trivially and not to the full extent.  Both swing and javafx are single threaded by design.  Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Sunday, August 4, 2024 at 16:30
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Detecting threading problems faster
Hi list,

I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX.  Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displayed, there can be no "hard" check everywhere to ensure we
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a
Platform.runLater wrapper was forgotten usually results in programs
operating mostly flawlessly, but then fail in mysterious and random and
hard to reproduce ways.  The blame is often put on FX as the resulting
exceptions will almost never show the user code which was the actual
culprit.  It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these
bugs originating from user code much earlier, similar to the
`ConcurrentModificationException` the collection classes do when
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part
of an active scene without too much of an performance impact, possibly
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance
(`getBean`).  This is an object, but we could check here if this
instance implements an interface:

      if (getBean() instanceof MayBePartOfSceneGraph x) {
            if (x.isPartOfActiveScene() && !isOnFxThread()) {
                 throw new IllegalStateException("Property must only be
used from the FX Application Thread");
            }
      }

This check could be done on every set of the property, and potentially
on every get as well.  It should be relatively cheap, but will expose
problematic code patterns at a much earlier stage.  There's a chance
that this will "break" some programs that seemed to be behaving
correctly as well, so we may want to put it behind a switch until such
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes,
we can think of good names if this moves forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/5baf719c/attachment.htm>