No, not at all. "busy waiting" means you use the CPU to constantly check
for a condition in a tight loop. Which is in general very bad:

    while(numQueuedEvents == 0) {
        ;    // burn CPU cycles
    }

A well written event-driven program releases the thread (the CPU) when
there is nothing to do. And the thread gets woken up once an event
arrives. It does/should check an exit condition in regular intervals if
the thread is supposed to be terminated prematurely. But that shouldn't
happen in a tight loop at all

Pseudo code (ignoring thread safety, exceptions, and many details):

    public void run() {
        while(!exitQueue) {
            if(numQueuedEvents == 0) {
                wait();    // give up CPU
            }
            Event e = getEventFromQueue();
            numQueuedEvents--;
            ...
            ...
        }
    }

    public void queueEvent(Event e) {
        addToQueue(e);
        numQueuedEvents++;
        enventHander.notify(); // wake up queue processing
    }

In lower-level terms we are talking about polling for some condition vs.
waiting for an interrupt informing about a condition.

/Thomas

Looking at the source of java.awt.Dialog.show, I'd call that magic. It's
huge and it uses non-public interfaces.

Technically there are events other than for the modal dialog that are
let through. For instance repaints.

"Foxtrot is a small but powerful framework for using threads with the
JavaTM Foundation Classes (JFC/Swing)."
  -- http://foxtrot.sourceforge.net/docs/introduction.php

Absolutely. Like that or with queues or similar. I tend to have the
non-EDT task and the invokeLater task separate.

What I really don't like about the Foxtrot approach is that the causing
event hasn't finished executing (obviously). So now you have problems of
listeners that haven't fired and of re-entrancy.

Tom Hawtin