Re: bugs regarding late g_thread_init() calls

[Yevgen Muntyan <muntyan tamu edu>]

Tim Janik wrote:

> On Thu, 4 Jan 2007, Yevgen Muntyan wrote:
>
> > Morten Welinder wrote:
> >
> > > I am looking around and I am having trouble finding a single 
> > > application
> > > that does this new (yes, new) required initialization right.
> > >
> > > Either...
> > >
> > > 1. Applications do not explicitly call g_thread_init and call 
> > > gtk_init too late.
> > > 2. Applications call g_thread_init too late.
> > > 3. Applications call g_thread_init too early.
> > >
> > > Does anyone want to claim a case that is right for a non-trivial 
> > > application?
> > > Something with a translated GUI.
> > Does this count:
> >
> > http://mooedit.sourceforge.net/hg/moo/?f=-1;file=medit/medit-app.opag
> > line 259.
>
>
> if you call g_mem_set_vtable(), you have to call it before any other
> glib function, including g_thread_init(). otherwise the vtable
> allocator you're plugging won't get paired alloc/free calls and get
> messed up.
> if you're calling g_slice_set_config(), you don't know what you're doing,
> it's declared *internal* API.

You're right, if I am doing evil things, I'm screwed up. But I am not doing
them [1]. Can I still have my cookie for a nice g_thread_init() user?

Regards,
Yevgen

[1] Long story short, the code with g_set_memtable has *never* been called
together with g_thread_init. I did use internal API in evil ways, but nobody
have seen, I checked.