Re: Swing application architecture question.
(f/u set to clj.gui)
Mark Space wrote:
I'd consider some queue of Runnables, that every 250 milliseconds
you wake up and drain the queue on the EDT. Bonus points if the EDT
task isn't called unless there's at least one Runnable in the queue.
Doesn't the AWT infrastructure do that on its own if you use
Mark Space wrote:
My point was to provide an explicit delay. I don't think invokeLater
Side note: While researching this I encountered this cautionary article:
Here are three Swing urban legends:
* Create threads for long tasks from the event dispatch thread.
* Use SwingUtilities for running tasks on the event dispatch thread.
* Synchronize methods for synchronization.
The first "legend" section discusses thread priority - it tells us that
we need to reduce priority on background threads spun off the EDT. I
had never heard that before.
Having heard it, my suggestion would be to ignore it.
The underlying assumption that a thread's Java priority is
the only thing that determines which threads run and which
thread wait is flawed. It is quite likely that the O/S
scheduler that ultimately decides "Who runs?" is entirely
unaware of the thread's Java priority: The J.P. is probably
mapped to a platform priority in a platform-specific way.
Also, the scheduler probably uses more inputs than just a
thread's priority: Solaris, for example, also looks at the
recent execution history to dynamically lower the priorities
of CPU-bound threads and raise those of event-bound threads.
(That's in the most common case; Solaris supports multiple
scheduling disciplines with different characteristics.)
Now, it may well turn out that on some platforms it is
desirable to juggle thread priorities to get best behavior
(for suitable values of "best"). Fine, and if so there's
nothing wrong with doing so. But don't do it _a priori_ and
without evidence that it's needed, and even when it's needed
I suggest doing it in platform-specific code.
For general issues (not necessarily Java issues) about
threading, thread priorities, and thread scheduling, visit
comp.programming.threads. There you will find the usual gang
of Usenet idiots, but also a few people who wrote the book on
threading, where "wrote the book" is meant literally.