Re: File browser
Peter Duniho wrote:
On Wed, 06 Feb 2008 09:24:42 -0800, Nigel Wade <nmw@ion.le.ac.uk> wrote:
[...]
I can easily write code that will consistently produce wrong results
with
incorrect synchronization. It's true that one can get lucky and have it
work without. But it's also true that it's relatively simple to force a
problem in order to demonstrate the risk of failing to synchronize.
Yes, but to do that you need to be in control of the competing threads.
With the EDT you are not.
Sure, you are. Any time you get your code to be called on the EDT, you
are now in control. Until your code returns, you remain in control.
If your initialization code is run on the main thread (or any thread other than
the EDT) you are not in control of the EDT. That's the entire point. Behind the
scenes, in code you don't have access to, Swing may start the EDT. When or what
starts the EDT isn't documented anywhere I have ever seen. To control the EDT
you *have* to initialize your GUI on the EDT.
The outdated guidance that you could initialize the GUI on the main thread, up
until the point that the first component was realized, I believe was based on
the assumption that that was when the EDT was started. At least that's how I
remember it being presented. However, that assumption was either incorrect, or
has been rendered incorrect by later changes to the internal workings of Swing.
All I need to know to write working code is that the GUI must be initialized on
the EDT. I don't really need to know why. I don't need to know exectly when the
EDT starts, only that it will start at some point and run my code correctly.
The innner workings are irrelevent to my code, just as I don't need to know the
inner working of TCP/IP stack in order to make an HTTP request of a web server.
So it should be simple enough to write code that intentionally causes
something to be called on the EDT, at which point one can take advantage
of that control to ensure a synchronization error.
It would be nice if you could provide a practical demonstration of that theory.
However, I doubt it's possible in reality because the timing issues which are
necessary to cause the synchronization error are probably not under your
control.
One of the previously-cited articles does in fact do something like this.
Unfortunately, because it's specifically using invokeLater() to get code
to execute on the EDT, it's not a demonstration of the problem I'm asking
about. It does reliably demonstrate the potential for a problem that
could occur when your own code intentially puts something for execution on
the EDT, but it doesn't help me better understand how someone could
unintentionally have something execute on the EDT prior to any components
being visible.
[...]
The EDT is event driven, events which are affected by user actions and
the
exact timing of those actions, plus other factors external to your
application
which are handled by the OS.
Before any components are shown, user actions won't affect when things are
executed on the EDT.
Yes, they will. The GUI is part of the windowing system. The windowing system is
part of the OS, or controlled by the OS. Events are passed from the
mouse/keyboard to the windowing system via the OS, and then on to your
application. The timing and order of those events, and the timing of exactly
when EDT is able to act on them, is dependent on what the OS and the user is
doing. The GUI of your application is not an isolated system.
So, what of those "factors external to your
application"? What factors exist during initialization, prior to any
components being shown, that might cause something to happen on the EDT?
I have no idea. You'd need to dig around for yourself in the internal workings
of the Swing source code to to discover that.
However, we know they do exist, we've seen them happen.
I should reiterate that none of my questions are intended to suggest that
the advice given is wrong. They are only intended to solicit more
information that would help me understand better what the specific risks
are.
Remember: "I don't know" is an acceptable answer. I just don't appreciate
the attitude conveyed to me that _I_ don't need to know.
There's sufficient observational evidence to support the fact that you have to
initialize on the EDT if you want your code to be reliable. The theory behind
this, whilst intellectually intersting, isn't a pre-reququiste to writing
reliable code.
Good luck in your search for the knowlege you desire. If you really, really have
to know this then you probably need to either contact Sun directly and ask
them, or get the source code and work it out for yourself. For myself, I'm
happy to follow the guidance and initialize my GUI on the EDT.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555