On Fri, Jan 11, 2002 at 11:11:12AM -0500, Jason Boxman wrote: > On Friday 11 January 2002 01:29 am, you wrote: > > The first alarm_adjust() call is redundant. The alarm should not be > > moved when the delta time is zero seconds. From around line 2215 in > > Kernel.pm: > > > > # Nothing to do if the delta is zero. > > return $kr_events[$alarm_index]->[ST_TIME] unless $delta; > > Fair enough, then if a single second had gone by and I did my call as above, > my future timeout would now by +239 seconds, yes? Each successive call to > alarm_adjust() in my SuccessEvent would add around another 120 seconds to the > timeout, effecively nullifying it. > > So how would implement a timeout? > > I thought I'd try $delta = alarm_adjust( $id ), alarm_adjust( $id , > (( time + 120 ) - $delta) to arrive at the difference necessary to bump the > alarm back up to only 120 seconds hence, but perhaps my math is off. > Sometimes doing (120 + time) - $delta would yield a slighty negative number > instead of a small positive one (I'm using Time::HiRes). > > Any idea what I should be doing?
As far as I can tell, you have two options. This will remove the previous delay and set a new one. The old ID is overwritten by a new one. $kernel->alarm_remove( $id ); $id = $kernel->delay_set( event_name => 120 ); You can also use the one-shot delay(). This will remove the old timeout for "event_name" and add a new one for time()+120. The drawback here is that you can't have more than one timeout for "event_name" in the same session. $kernel->delay( event_name => 120 ); Also see: http://poe.perl.org/?POE_Cookbook/Recurring_Alarms -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
