Detecting threading problems faster

[quizynox]

Hello,

Wouldn't it be better to implement this check in assert to avoid any impact
in production?

пн, 5 авг. 2024 г. в 03:30, John Hendrikx <john.hendrikx at gmail.com>:

> 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/a9389d0f/attachment-0001.htm>