2

Is there any way to determine how many Runnables are currently queued in the EventQueue?... I mean the system EventQueue, i.e. all the Runnables to be run in the EDT. And mess with the queue, maybe?

What I want to do is to prioritise GUI Runnables... if a user-driven GUI event comes along it should be executed immediately, jumping the queue before any queued Runnables (which, by the way, are all going to be concerned with modifying non-visible Swing components. NB latest Swing guidelines: ALL Swing components must be changed on the EDT, even if hidden).

There are possibilities for a simple, contrived queue with "urgent" and "non-urgent" Runnables: each Runnable could increment an "observable" AtomicInteger counter, and then the execution of each could decrement it... and a BlockingQueue would ensure that non-urgent Runnables would only be submitted to "invokeLater" if the BlockingQueue size changed down to 1 (or 2 or 0 perhaps). Instinct makes me think such an arrangement would introduce quite a bit of latency though.

Plus it'd be nicer to be able to interfere with the EDT's own queue directly. Should I maybe roll my own EDT queue? Is that possible?

NB obviously observation of the state of the EDT queue (or intervention on it) would have to be done from a non-EDT thread. There may be "thread visibility" issues for all I know...

Zoyd
  • 3,449
  • 1
  • 18
  • 27
mike rodent
  • 14,126
  • 11
  • 103
  • 157
  • It might be easier to have a background thread with an infinite loop that consumes elements from a `PriorityBlockingQueue`, passing each to `EventQueue.invokeLater`. Of course, you would need either a Comparator to determine each Runnable's priority, or you would have to make the Runnables themselves mutually Comparable. – VGR Dec 10 '12 at 00:53
  • 2
    I think it's a bad idea to try to prioritize events on the `EventQueue`. There's a reason that all GUI code is run on a single thread: event order needs to be preserved. Whilst it's relatively easy to implement your requirement, I think that once implemented you'll start to have problems with event ordering. I recommend re-thinking the requirement. Are urgent events truly delayed for too long? Does a user even notice this delay? If yes, and yes, I'd have a look at why there's a noticable delay (there shouldn't be). Ensure there's no long running events (eg IO-bound) on the queue. – Muel Dec 10 '12 at 01:01
  • Both of these are excellent answers... thanks. @Muel - preservation of event order, yes, right... The fact that the hidden (parallel) Swing components in question are kind of isolated from what's going on in the foreground one doesn't change the principle you mention. Won't bore with details, but I shall now try looking at the situation in a different way! – mike rodent Dec 10 '12 at 06:21
  • the question in your title and first paragraph is completely different from the text... could you edit the title to reflect your intentions? – Silly Freak May 21 '14 at 21:23

1 Answers1

1

I don't think it's possible. The code is available. You could override it and even rewrite it, but the actual EventQueue is set up by the system; you can't get to it except through a few defined methods. You can certainly set up your own and use that, but all the Swing components are going to use the official EQ and you'll end up doing multithreaded Swing. (From personal experience this works very well, except for the occasional, aggravating, inexplicable bit of odd behavior. My advice: never even think about a Swing component unless you're on the EventQueue.)

(If you do look at it: the 1.4 EventQueue class was a beautiful piece of code. 1.7 seems to use thread-safe, non-blocking skip lists instead of the old wait/notify. I'm sure it's fast, but the code's a monster. If you do want to build your own queue for any reason, try to get the 1.4 code for a starting point. Java ought to have a generic execution queue class, but I've yet to find one.)

You really shouldn't be having much trouble with the EventQueue performance. It should be using much less than a CPU second each second. Unless you're dropping a lot of CPU intensive runnables into it, you shouldn't need to worry about it. If you are, you might consider putting the work in another thread. (Though occasionally slowing the UI seems a small price to pay for keeping everything in a single thread.) Reordering the queue probably won't help much anyway. The runnable that you want to process quickly is bound to arrive immediately after the start of some big calculation.

If you just want to run your own runnables in order, you can set up a class that keep a sorted list of runnables. It would have it's own runnable, which you can drop in the EQ with InvokeLater. When it runs, it, in turn, can run each of it's runnables in your desired order. But this only helps if you need your runnables sorted for your own purposes.

If you are only working with Swing components, visible or otherwise, you'll probably do just fine using the EQ as designed with InvokeLater for everything.

RalphChapin
  • 3,108
  • 16
  • 18
  • thanks for clarifying the issue. I won't be indulging in any EDT/Swing heresy... you can't be sure of much with concurrency, except that such heresy will come back, maybe months later, to bite you in the bum at the worst possible opportunity! – mike rodent Dec 10 '12 at 06:31