-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Fromreide
Sent: Friday, September 30, 2005 11:13 AM
To: [email protected]
Subject: Re: Patch for delaying of tasks attached to snmp_alarm_register
On Fri, Sep 30, 2005 at 10:41:13AM -0700, Juan Betty-MGIA2720 wrote:
> Oops, must be the multitasking problem. This should work -
>
> --- snmp_alarm.c.old 2005-09-28 11:03:28.000000000 -0700
> +++ snmp_alarm.c 2005-09-30 09:20:30.000000000 -0700
> @@ -223,6 +223,7 @@
> return NULL;
> }
>
> +static timeval t_last_run_alarms={ 0, 0 };
> void
> run_alarms(void)
> {
> @@ -231,6 +232,16 @@
> unsigned int clientreg;
> struct timeval t_now;
>
> + int timeBackFlag = 0;
> + gettimeofday(&t_now, NULL);
> + if( (t_now.tv_sec < t_last_run_alarms.tv_sec) ||
> + ((t_now.tv_sec == t_last_run_alarms.tv_sec) && (t_now.tv_usec <
> t_last_run_alarms.tv_usec) )
> + ) { // we have a clock going back reset the timers
> + timeBackFlag =1;
> + }
> + t_last_run_alarms.tv_sec = t_now.tv_sec;
> + t_last_run_alarms.tv_usec = t_now.tv_usec;
> +
> /*
> * Loop through everything we have repeatedly looking for the next thing
> to
> * call until all events are finally in the future again.
> @@ -243,13 +254,14 @@
>
> gettimeofday(&t_now, NULL);
>
> - if ((a->t_next.tv_sec < t_now.tv_sec) ||
> + if ( timeBackFlag || (a->t_next.tv_sec < t_now.tv_sec) ||
> ((a->t_next.tv_sec == t_now.tv_sec) &&
> (a->t_next.tv_usec < t_now.tv_usec))) {
> clientreg = a->clientreg;
> DEBUGMSGTL(("snmp_alarm", "run alarm %d\n", clientreg));
> (*(a->thecallback)) (clientreg, a->clientarg);
> DEBUGMSGTL(("snmp_alarm", "alarm %d completed\n",
> clientreg));
> + timeBackFlag = 0;
>
> if ((a = sa_find_specific(clientreg)) != NULL) {
> a->t_last.tv_sec = t_now.tv_sec;
>
>
Yes - this should fix problem #0, have you thought about #1 and #2 yet as those
are he hard ones?
> Now to the problems with the patch:
>
> 0) It doesn't apply since it is malformed (Chunk 1 and 2 lacks one line each)
> This I am certain is just a cut'n-paste mistake or some such :-)
>
> 1) It might end up running things early if the time went backwards. Now I do
> not say that early is worse than late, I just say that it is't much better
> either.
>
In my case, most tasks attached to the snmp_alarm just need to be spawned, and
there is logic, like checking to see if there are traps waiting, within the
task to determine whether more need to be processed. For this type of
application, it doesn't hurt to run a bit early once. But this wouldn't work
well if the spawn time has to be precise.
> 2) It handles only one outstanding timeout, if there are two in the queue that
> should happen in the next minute and you set back the clock an hour your
> patch will run the first one and the second one will be delayed.
>
> Now, to run every timeout is also wrong, what is needed is a way to tell
> how big the time warp was and then adjust timeouts that should wait for
> N time units but leave those that should run at a certain time alone.
>
> The size of the timewarp could probably be found using something like
> clock_gettime(CLOCK_MONOTONIC, ...) but that is not a required interface.
> Also note that this could be used to detect forward warps.
>
I think the concept is correct, but am unsure about the implementation.
/MF
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and
more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
