The short answer: POE doesn't have a public method to query the event queue. If it did, the generic "grep the event queue" would be slower than just checking a flag.

The medium answer: POE::Queue::Array has a generic query mechanism, but POE::Kernel doesn't expose it. Even if it did, searching the queue would be an O(N) operation while maintaining and checking a flag are O(1).

The long answer:

POE's event queue is an ordered heap, implemented using a Perl array. It's done this way to make inserting events fast (that's O(N) for small queues and O(log N) for large ones). Removing the next event is always an O(1) operation.

So POE is optimized for what you do most of the time: Posting events, setting timers, and dequeuing the next event. Actually finding an event in the queue is not optimize, so it's quicker (although more work for you) to manage a flag.

You could create a small function library to keep track of special one-shot timers, though. Something like this untested code:

my %pending;

sub set_oneshot_timer {
  my ($event, $hence) = @_;
  my $session_id = $poe_kernel->get_active_session()->ID();
  return if exists $pending{$session_id}{$event};
  $poe_kernel->delay( $event, $hence );
  $pending{$session_id}{$event} = 1;
}

sub caught_oneshot_timer {
  my $event = shift;
  my $session_id = $poe_kernel->get_active_session()->ID();
  delete $pending{$session_id}{$event};
  delete $pending{$session_id} unless keys %{$pending{$session_id}};
}
[download]

To use it:

sub some_event_handler {
  # set a timer for 10s from now, unless it's already set
  set_oneshot_timer( event_to_send => 10 );
}

sub handle_timer_event {
  # caught the timer; clear the flag
  caught_oneshot_timer($_[STATE]);
}
[download]

I hope this helps.

-- Rocco Caputo - http://poe.perl.org/

Thanks. I wrote this as a flag setting/checking operation but didn't think that was the right way to do this. I guess so. Thanks for clarifying the proper practice.

       Original alarm and delay methods:

...
         # Post an event which will be delivered after a delay, specif
+ied in
         # seconds hence. This clears previous timed events with the s
+ame
         # name.
         $kernel->delay( $event, $seconds, @event_args );

         # Post an additional delay, leaving existing ones in the queu
+e.
         $kernel->delay_add( $event, $seconds, @event_args );

       June 2001 alarm and delay methods:

...
         # Post an event which will be delivered a number of seconds h
+ence.
         # This does not clear previous events with the same name.
         $alarm_id = $kernel->delay_set( $event, $seconds_hence, @etc 
+);
...
         # Refresh an existing delay to a number of seconds in the fut
+ure.
         $kernel->delay_adjust( $delay_id, $number_of_seconds_hence );

...
[download]