Re: invokeLater and weird race conditions in my swing app
I am not a Swing guru, but recognize that Swing is analogous to X, if an X
server were allowed to receive non-GUI requests at the programmer's
No. The X server is a separate dedicated process that can only rcv and
process graphics messages. It cannot do anything else.
Um, yes, I am aware of this. I was positing a hypothetical situation in order
to draw an analogy.
In that world, the programmer would have to be sure not to
send such requests to the X server,
This cannot happen. X just doesnt [sic] work that way.
Surely it was clear from my comments that I am aware of this, and was
presenting a hypothetical analogy. I was calling upon you to use your
imagination, and see what would happen /if/ X were allowed to handle non-GUI
events. That's /if/, as in it's a thought experiment, not a description of
present reality as it actually is.
All I was saying was in that clearly hypothetical, not currently real
scenario, were it to be so and not just in my imagination and in anyone else's
following this argument, as I say, in that entirely fictional situation then X
might, were it like that actually, have similar issues, if that were so, which
it isn't, really.
just like in Swing one must avoid performing non-GUI work in the EDT.
This is the difference. In X you dont have to worry about it, in swing
This isn't really "the difference", it's a manifestation of the differences.
Remember, X is a black-box fully-developed out-of-process application; Swing
is a low-level, white-box, in-process API. With X, someone else is the
programmer; with Swing, you are.
Thanks for clarifying comments, I am still struggling but my initial
fears seem to be confirmed.
I still think you have it backwards. Anyway, either way, the bottom line is
that as an API, the Swing library is like any other API where threads are
involved. As programmers we get to manage the issues; with X someone else did
that for you.
Anyway, fear and loathing in Las Vegas aside, the hard fact is that you must
be aware of the multithreaded nature of Swing programs to use the library.
- all, absolutely all graphical work /must/ happen on the EDT;
- long-running tasks like resource access might tie up the GUI unacceptably
if run on the EDT, so:
- do not run business logic on the EDT.
That might not be easy, but that's why they pay us the big bucks.