<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 07/08/2024 21:38, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">John:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Looks
like the issue in PR#1123 was caused by application code
accessing FX from a non-FX thread.</span></p>
</div>
</blockquote>
That does seem likely, but it is incredibly hard to be sure.<br>
<blockquote type="cite"
cite="mid:BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I
know the discussion is about trying to detect thread misuse
early on, as a way to help the application developers. I
vaguely recall the discussion we had at some point about
adding the check to property invalidation code or some such,
and the general consensus was that it might pose a
compatibility risk or something along these lines.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Perhaps
there is a place where such a check might be safely made (I
don't know of any such place though)? We did, after all,
step on the path of simplification (?) for the sake of
students (see <a href="https://openjdk.org/jeps/445"
moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/jeps/445</a>
). Perhaps such a check could be hidden behind a system
property so as not to break existing, if poorly written,
applications.
</span></p>
</div>
</blockquote>
<p>I agree that we should be careful not to break anything, it is a
check, but I also think that most developers will want this check
on (but probably not by default initially, but definitely
**after** they fixed any mistakes it detected to avoid
recurrence). There is nothing worse than code that only rarely and
inexplicably fails on other machines.<br>
</p>
<p>For me, I wouldn't hesitate for a moment to turn checks on that
alert me of incorrect use of FX -- I value my time, and bugs
resulting from these threading problems can be very costly to
track down. I already wrote my own check that scans for dead
"nodes" (ie. nodes that were once part of a scene graph, but are
no longer, but are still not being GC'd).<br>
</p>
<blockquote type="cite"
cite="mid:BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Personally,
I feel that it should be the first thing taught - always
call FX from the FX application thread.</span></p>
</div>
</blockquote>
Even Java collections will help you avoid threading problems by
throwing ConcurrentModificationException. Imagine a moment a world
where this check did not exist, as it does cost some performance (a
mod counter is increased on every collection modification):
<p>- Concurrent access to things like HashMap and ArrayList would
seem to work fine<br>
- Sometimes randomly, an item goes missing, is overwritten or
duplicated, or the code gets stuck in an infinite loop (these are
all possible outcomes of concurrent collection access, as the
check isn't perfect, so when you do see it, you must investigate
thoroughly)<br>
- The bug is reported (collection framework is buggy!)<br>
- After analysis, culprit is that the user somewhere in their
100.000+ line code base is accessing a collection on different
threads... sorry, we can't help you further.<br>
- Except, they could help us further:
ConcurrentModificationException was included at a slight cost of
performance. It can't even be disabled (I'm not implying this was
a later addition, the designers were just aware that this would
lead to hard to track bugs and added this immediately).<br>
</p>
<p>The parallels with the FX threading model, and also with weak
references are huge:</p>
<p>- Both "seem" to work fine, until they don't<br>
- Failures are very random, may not occur at all on some setups
(like the developer's), and failures can be subtle, deceiving or
complete<br>
- The bug is reported (FX doesn't even check for nulls in Scene
code!)<br>
- After analysis, culprit is (likely) that the user somewhere in
their 100.000+ line code base is accessing the scene graph on
different threads / forgot to maintain a hard reference... sorry,
we can't help you further.<br>
</p>
<p>These kinds of mistakes are not just happening to beginners.
This can happen when code gets rearranged, its original operating
parameters long forgotten by you, or some future maintainer. All
it takes is a moment of inattention and you have a bug that you
may never personally encounter, and when it does occur is
impossible to reproduce with any certainty and does NOT give any
indication of the cause (you see only symptoms). Such bugs are
the nastiest kind, and it is (IMHO) a failure of a framework to
not help you detect these as early as possible.</p>
<p>--John<br>
</p>
<br>
<blockquote type="cite"
cite="mid:BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I am
curious what other members of community think of this issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">John
Hendrikx <a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a><br>
<b>Date: </b>Wednesday, August 7, 2024 at 12:01<br>
<b>To: </b>Andy Goryachev
<a class="moz-txt-link-rfc2396E" href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a>,
<a class="moz-txt-link-abbreviated" href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>[External] : Re: Detecting threading
problems faster<o:p></o:p></span></p>
</div>
<p>Hi Andy,<o:p></o:p></p>
<p>Problems that occur due to modifying the scene graph
(like adding/removing children, or changing certain
properties) can be incredibly subtle, and almost never
point out the code that is the actual culprit. I suspect
that the PR below is one of those for example, but there
are likely many more.<o:p></o:p></p>
<p><a
href="https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1123__;!!ACWV5N9M2RV99hQ!ILqOOB9ua4tDxfAV9pGPJJiQ3oXewiSQjH2BCsaQkhpgkHEQzT8hRQt2fb9mKjYbF24ZRpQwfEiELFvn4B28lBLwxrTE$"
moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1123</a><o:p></o:p></p>
<p>Issues that complain about some kind of odd bug in the FX
code (like a NPE, ConcurrentModificationException,
ArrayIndexOutOfBoundsException, etc) could all be caused
by user code doing things on the wrong thread, but its
really hard to diagnose as the stack traces provided will
never point out the user code that may be the culprit.
I've investigated PR 1123 extensively, and I can't see any
bugs in the FX code at all **assuming** it is used from a
single thread...<o:p></o:p></p>
<p>--John<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">On
05/08/2024 17:01, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">John:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Can
you cite a bug or give an example of such a problem?</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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?</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt;color:black">From:
</span></b><span
style="font-size:12.0pt;color:black">openjfx-dev
<a href="mailto:openjfx-dev-retn@openjdk.org"
moz-do-not-send="true">
<openjfx-dev-retn@openjdk.org></a> on
behalf of John Hendrikx <a
href="mailto:john.hendrikx@gmail.com"
moz-do-not-send="true">
<john.hendrikx@gmail.com></a><br>
<b>Date: </b>Sunday, August 4, 2024 at 16:30<br>
<b>To: </b><a
href="mailto:openjfx-dev@openjdk.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">openjfx-dev@openjdk.org</a>
<a href="mailto:openjfx-dev@openjdk.org"
moz-do-not-send="true">
<openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>Detecting threading problems
faster</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:11.0pt">Hi list,<br>
<br>
I know of quite some bugs and users that have
been bitten by the <br>
threading model used by JavaFX. Basically,
anything directly or <br>
indirectly linked to an active Scene must be
accessed on the FX thread. <br>
However, as FX also allows manipulating nodes
and properties before <br>
they're displayed, there can be no "hard"
check everywhere to ensure we <br>
are on the FX thread (specifically, in
properties).<br>
<br>
Now, I think this situation is annoying, as a
simple mistake where a <br>
Platform.runLater wrapper was forgotten
usually results in programs <br>
operating mostly flawlessly, but then fail in
mysterious and random and <br>
hard to reproduce ways. The blame is often
put on FX as the resulting <br>
exceptions will almost never show the user
code which was the actual <br>
culprit. It can result in FX being perceived
as unstable or buggy.<br>
<br>
So I've been thinking if there isn't something
we can do to detect these <br>
bugs originating from user code much earlier,
similar to the <br>
`ConcurrentModificationException` the
collection classes do when <br>
accessed in nested or concurrent contexts.<br>
<br>
I think it may be possible to have properties
check whether they're part <br>
of an active scene without too much of an
performance impact, possibly <br>
even behind a switch. It would work like this:<br>
<br>
Properties involved with Nodes will have an
associated bean instance <br>
(`getBean`). This is an object, but we could
check here if this <br>
instance implements an interface:<br>
<br>
if (getBean() instanceof
MayBePartOfSceneGraph x) {<br>
if (x.isPartOfActiveScene()
&& !isOnFxThread()) {<br>
throw new
IllegalStateException("Property must only be <br>
used from the FX Application Thread");<br>
}<br>
}<br>
<br>
This check could be done on every set of the
property, and potentially <br>
on every get as well. It should be relatively
cheap, but will expose <br>
problematic code patterns at a much earlier
stage. There's a chance <br>
that this will "break" some programs that
seemed to be behaving <br>
correctly as well, so we may want to put it
behind a switch until such <br>
programs (or libraries) can be fixed.<br>
<br>
What do you all think?<br>
<br>
--John<br>
<br>
(*) Names of methods/interfaces are only used
for illustration purposes, <br>
we can think of good names if this moves
forward.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>