gobject.timeout_add timeout recalculation

[Mitko Haralanov-2]

In my application, I am using gobject.timeout_add to trigger periodic
updates of the status of a number of machines.

However, I am having a bit of trouble understanding exactly how the
timeout is calculated. According to the documentation:

        After each call to the timeout function, the time of the next
        timeout is recalculated based on the current time and the
        given interval (it does not try to 'catch up' time lost in delays).

The "After each call to the timeout function,..." leads me to think
that the timer is reset when the timeout function returns. However, the
phrase "(it does not try to 'catch up' time lost in delays)." makes me
think that the timer is reset as soon as the timeout function thread is
started. (This also seems to be confirmed by tracing my code)

What I would like to happen is that the timeout gets recalculated when
my timeout function is done/returns. I guess, I could add a new timeout
from within my timeout function and have it [the timeout function]
return False (so the old timeout is destroyed) but I am thinking that
there has to be a better way to do this.

I appreciate any advice on the matter.
--
Mitko Haralanov
==========================================
A Fortran compiler is the hobgoblin of little minis.
_______________________________________________
pygtk mailing list   pygtk@...
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[smontanaro]

    Mitko> However, I am having a bit of trouble understanding exactly how
    Mitko> the timeout is calculated. According to the documentation:

    Mitko>      After each call to the timeout function, the time of the
    Mitko>      next timeout is recalculated based on the current time and
    Mitko>      the given interval (it does not try to 'catch up' time lost
    Mitko>      in delays).

    Mitko> The "After each call to the timeout function,..." leads me to
    Mitko> think that the timer is reset when the timeout function returns.
    Mitko> However, the phrase "(it does not try to 'catch up' time lost in
    Mitko> delays)." makes me think that the timer is reset as soon as the
    Mitko> timeout function thread is started. (This also seems to be
    Mitko> confirmed by tracing my code)

I believe it works like this:

    set wakeup for X milliseconds from now
    call your callback
    if it returned true:
        set wakeup for X milliseconds from now
    call your callback
    if it returned true:
        set wakeup for X milliseconds from now
    call your callback
    if it returned true:
        set wakeup for X milliseconds from now
    ...

If X is 2500ms and your callback takes 2ms to execute, the interval between
successive calls will actually be 2502ms.
   
    Mitko> What I would like to happen is that the timeout gets recalculated
    Mitko> when my timeout function is done/returns. I guess, I could add a
    Mitko> new timeout from within my timeout function and have it [the
    Mitko> timeout function] return False (so the old timeout is destroyed)
    Mitko> but I am thinking that there has to be a better way to do this.

In our applications we added an abs_timeout_add function which takes hour,
minute, second and microsecond.  The callback is called at the same time
each day by taking into account the runtime of the callback.  You could do
something similar with a shorter period.

Skip

_______________________________________________
pygtk mailing list   pygtk@...
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[Mitko Haralanov-2]

On Thu, 15 May 2008 18:48:22 -0500
skip@... wrote:

> I believe it works like this:
>
>     set wakeup for X milliseconds from now
>     call your callback
>     if it returned true:
>         set wakeup for X milliseconds from now
>     call your callback
>     if it returned true:
>         set wakeup for X milliseconds from now
>     call your callback
>     if it returned true:
>         set wakeup for X milliseconds from now
>     ...
>
> If X is 2500ms and your callback takes 2ms to execute, the interval between
> successive calls will actually be 2502ms.

Unfortunately, it is how it work. In fact, that how I would like it to
work. Here is what my testing shows:

t0: set wakeup for X milliseconds from now
t0+X: set wakeup for X milliseconds from now (t0+X+X)
        call callback
        if it returned true: noop
        else: delete the timer

Here is an example:

#!/usr/bin/python

import gtk
import gobject
import time

def callback (timeout):
  print "callback called at: %s"%time.time ()
  time.sleep (timeout)
  print "callback returning at: %s"%time.time ()
  return True


if __name__ == "__main__":
  gobject.timeout_add (20*1000, callback, 10)
  gtk.main ()


If you run this, you get:
callback called at: 1210897497.69
callback returning at: 1210897507.69
callback called at: 1210897517.69
callback returning at: 1210897527.69
callback called at: 1210897537.69
callback returning at: 1210897547.69
callback called at: 1210897557.69


Note that the time difference between the "callback returning at" and
"callback called at" is not 20 seconds but 10 seconds (20 second timeout
- 10 second callback runtime).

--
Mitko Haralanov
==========================================
A programming language is low level when its programs require attention
to the irrelevant.
_______________________________________________
pygtk mailing list   pygtk@...
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[smontanaro]

    >> If X is 2500ms and your callback takes 2ms to execute, the interval
    >> between successive calls will actually be 2502ms.

    Mitko> Unfortunately, it is how it work. In fact, that how I would like
                               ^ not?
    Mitko> it to work. Here is what my testing shows:

Hmmm...  It would appear the documentation is wrong.  I thought in the past
I remember seeing it work the other way.  I can't reproduce it with the
versions I have installed (2.6 and 2.10 at work and 2.12 at home).  I'm
installing gtk 1.2.10 on my Mac now.  I'll see how it works there.  (If I
can get it installed...)

Skip

_______________________________________________
pygtk mailing list   pygtk@...
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/