Re: weird gtk_timeout_add ...

[Peter Rottengatter <peter rottengatter de>]

Havoc Pennington wrote about "weird gtk_timeout_add ..." :

> > 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.

Ah, I didn't know that. The docs do not mention that. So it's because
precision isn't there, only accuracy is.


> > 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.

C experience does not tell at all if a function returning a (char *) in
fact just returns a pointer to an internal string, or returns a malloc'd
copy of such a string. As it's less abusive of CPU power, I indeed had
suspected that the former is the case, such that free() must not be used.
If a malloc'd copy were required, the app could still do that. But I
learned that GTK does not work that way.


> Normally if you call foo_new() to create something, you later need to
> call the corresponding foo_unref() or foo_destroy().

Hmmm. What I wondered: I have an optionmenu that has some menu attached.
I need to change a lot of the menu, so I build a new one, and attach it 
with gtk_option_menu_set_menu. I'd guessed that would create a leak, so I 
looked for some way to get rid of the old menu properly. I think, calling
gtk_option_menu_remove_menu prior to attaching the new one does the job.
But I'm still not sure if something needs to be freed. Do I need to
foo_destroy the thing ?

It's all the lack of documentation, and the result of guesswork.


> 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

I haven't found a single point in the GTK 1.2 docs where it's pointed
out that the result of some function needs to be freed after use.


> , in GTK 2.0 the ones that
> should not be freed are given as "const char*" instead of "char*"

That could be a helpful rule. With the only flaw of not being applicable
to GTK 1.2 ;-)


Cheers  Peter
-- 
---------------------------------------------------------------------
      Dr. Peter Rottengatter       peter rottengatter de
                                   http://www.rottengatter.de
---------------------------------------------------------------------