Detecting threading problems faster

[Thiago Milczarek Sayão]

It seems Task<> has thread checks, it would even correct the thread on
updateMessage().

So, it seems to be a problem if Task<> is not used?



Em seg., 5 de ago. de 2024 às 12:01, Andy Goryachev <
andy.goryachev at oracle.com> escreveu:

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