The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.
That sounds like a misunderstanding of how the actor model works. An actor doesn't wait. It's an event-driven system, it doesn't get to own and decide when messages get fed to it.
Well in mine for example, threads are pinned to a core and always spin, and actors are pinned to a given thread (you can have an arbitrary number of actors per thread, they're just objects), so "waiting" is certainly not something you'd use to describe the setup in any capacity.
An actor does not have a queue; that's again the whole point I already made: it's event-driven, things are decoupled and the actor is not aware of how control flow happens.
Regardless, when the queue which exists and is per-thread is empty, the program terminates.