On Mon, Jun 04, 2001 at 05:10:06PM -0700, Wilkinson, Mike wrote:
>
> I appear to have confused myself. The order for POE's built-in select
> appears to be:
>
> I/O callbacks (from wheels and such)
> alarms (zero or negative times remaining)
> queued states (via yield)
>
> Signals appear to be all over the place, depending on which one it is.
>
> Still not sure how Event.pm effects this however, I need to install it
> first.
>
> - MW
The priority of I/O callbacks and alarms may vary depending on the
event loop, but queued events are handled by the loop's "idle"
callback. That gives them the lowest priority across the board. I
can't guarantee this for future event loops, though I'll try to ensure
it. If some event loop doesn't have an idle callback (or a local
equivalent), then the priority might change.
Regardless of the event substrate (Select, Event, Gtk, Tk, or some new
one), I work to keep event dispatch order deterministic:
Signals are enqueued at the time the signal is caught. They're
dispatched whenever they reach the start of the FIFO event queue. I
did this to minimize the work done in signal handlers. Enqueuing an
event is several times cheaper than dispatching a signal.
I/O callbacks are dispatched willy-nilly because they can occur in any
order. They aren't queued because select() would keep signalling that
a file was ready 'til the event was dispatched. That could be several
iterations of the main loop in $poe_kernel->run(), and each iteration
would see a duplicate "hey, it's ready!" enqueued.
Alarms are dispatched in time order. Where two or more alarms are set
for the same time, they are dispatched in the order in which they were
set. They have priority over FIFO events on the assumption that
they've been waiting a while to be dispatched. time() is frozen (into
$now) for the duration of a dispatch iteration, so the alarm queue
will eventually catch up.
Queued states are dispatched in FIFO order, after everything else is
done.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
