Re: weird gtk_timeout_add ...

[Havoc Pennington <hp redhat com>]

Peter Rottengatter <peter rottengatter de> writes:
> Hmmm, the docs say the first parameter of gtk_timeout_add is the number
> of milliseconds between successive events triggering the timeout handler.
> So "gtk_timeout_add (10, check_progress, widget);" means call the handler
> check_progress every 10ms. Now the handler has as the first lines
> |  static int cnt=0;
> |  printf("%d\n",cnt++);
> So I'd expect counting to 1600 would take 1600 x 10ms = 16s. It doesn't.
> It does take twice as long: 32s. Using a 20ms timeout, the total time is
> still 50% longer than expected. The machine is not a particularly slow one,
> and the result is independent of what else is done in the timeout handler. 
> This is GTK 1.2.5. Any explanations ?

The system timer on most computers only has about a 10ms resolution.
Also, neither most kernels nor the GTK main loop are real time
systems, so they can't make any kind of guarantees about
scheduling. So timeouts aren't going to be very precise, they are just
a rough thing.

> I'm sure my program has lots of memory leaks, because nowhere exists
> a description of where I'd need to use g_free(). Is there a simple
> rule telling which objects need to be g_freed ?

It should be fairly intuitive if you've used C a lot. Other than that,
no, there's a set of guidelines, with some exceptions.

Normally if you call foo_new() to create something, you later need to
call the corresponding foo_unref() or foo_destroy(). Of char* strings
returned from functions, some require freeing and some don't, in GTK
1.2 you have to look at docs or source code, in GTK 2.0 the ones that
should not be freed are given as "const char*" instead of "char*"

Havoc