Re: current_time in main loop

[Owen Taylor <otaylor redhat com>]

Scott Gifford <sgifford@tir.com> writes:

>   I haven't been actively following this thread, but wanted to point
> out a bug that I reported a few weeks ago in a similar vein, at:
> 
> 	http://bugs.gnome.org/db/41/4156.html
> 
> , in which the timer code gets confused when a machine goes to sleep,
> and the delay between two function calls could be several days.  I
> just wanted to make sure anybody making changes to the timer handling
> code took these possibilities into account.
> 
>   If this isn't really relevant, please ignore.  :)

Well, its not really relevant in the sense that it is unrelated
to the problem we are discussing here, which is a lot more
subtle. 

There is no doubt, however, that your problem should definitely be
fixed if possible. I don't think the patches you proposed are quite
right - your change in g_timeout_prepare() is, as far as I can see,
simply going to result in glib eating 100% CPU until the timeout
expires at the time it would otherwise - since the check in
g_timeout_check() isn't affected. What I think we want to do is
something like:

 if (msecs > data->interval)
   {
      guint seconds = data->interval / 1000;
      guint msecs = data->interval - seconds * 1000;

      data->expiration.tv_sec = current_time->tv_sec + seconds;
      data->expiration.tv_usec = current_time->tv_usec + msecs * 1000;
      if (data->expiration.tv_usec >= 1000000)
        {
          data->expiration.tv_usec -= 1000000;
          data->expiration.tv_sec++;
        }
   } 

Which actually is a bunch of code cut-and-pasted from g_timeout_dispath(),
which actually also occurs in g_timeout_add_full(), so that code
needs to be moved into a separate function. 

One thing I don't understand is your statement that a problem
occurs in both the case where the system clock is set forward
and in the case where the clock is set back. I see the problem
when the clock is set back, but if the clock is set forward, then:

 - The timeout in g_timeout_prepare will be computed  as negative,
   so will be clipped to zero.

 - g_timeout_check() is unaffected by such a clock change.

Your comment about '40 days' makes it sound like we have
a problem somewhere with a negative msecs value being treated
as a large positive value, but I don't see such a problem.

As for the change to gtimer.c - I don't think that it is necessary.
gtimer.c is code for timing an event - and if the system clock
changes during such a timing operation, I don't know if 0
is a more reasonable value than a negative value.

Regards,
                                        Owen