On Sun, May 23, 2004 at 12:13:07AM +0000, Ton Hospel wrote:
> I was writing some code where I wanted to detect if the system was 
> "idle" by having a yield event going round and round and seeing if 
> anything happens inbetween. This works reasobably well, except when
> POE uses Tk. To demonstrate:

[...]

> Was I depending too much on internal details in expecting a pure 
> switching between readable and yielder ?

I think you are, yes.  POE can guarantee a certain order between
"message" events (those sent by post or yield), but it can't ensure
consistency between different types of events.

POE is at the mercy of the underlying event loop.  POE's own loops are
used for select() and IO::Poll, so they're not a problem.  POE relies
on callbacks from Event, Gtk, or Tk to drive its own event queue.
Timing differences in those libraries will affect the synchronization
between message and I/O event types.

The event loop libraries may require Ugly Workarounds to behave
properly.  Tk, for example, will starve I/O watchers if you start a
0ms after() timer from a timer callback.  In your example, the
recursive yield() would prevent select_read() from ever seeing
activity on the pipe.

That sort of Ugliness can also affect the timing of messages vs. I/O.

So.  I can't sanely guarantee it at this point, if ever.  I'd like to
see more event loops supported, and there's no telling what strangness
will need to be dealt with in the future.

Whew.  Now, to solve your problem.

It might be more reliable to use small delays, perhaps on the order of
1/100 second, to detect idleness.  It also might be more efficient, as
actual work will have precedence over the idleness polling loop.

In tests, replacing yield("yielder") with delay("yielder", 0.01)
results in (Tk) output like:

  yielder
  readable
  readable
  yielder
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  yielder
  readable  <-- potential problem
  yielder
  readable
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder

Here's how it looks with select():

  1) poerbook:~/projects/support% perl ton-dispatch-order.perl
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable
  readable
  readable
  readable
  yielder
  readable    <-- potential problem
  yielder
  readable
  readable
  readable
  readable
  yielder

The potential problems are cases where we almost falsely detected
idleness.  A higher delay value might help.

-- Rocco Caputo

Reply via email to