Re: glib memory allocation problems

[Miklos Szeredi <miklos szeredi hu>]

> >>> So the question is, should glib not make some sanity checking for code
> >>> that is not actually thread related (like gslice).
> >>
> >> it does do sanity checking, it throws a big bold warning if you call
> >> thread_init and gslice in the wrong order:
> >>    http://blogs.gnome.org/view/timj/2007/01/02/0
> >>    http://bugzilla.gnome.org/show_bug.cgi?id=331853
> >
> > But if g_thread_init() was not called _at all_, it just silently
> > corrupts the data structures.
> 
> no, gslice works perfectly fine in a single threaded program.
> 
> > And this is perfectly possible if program is using the pthread API,
> > while using glib for hash tables, etc.
> 
> if you use the pthread API without calling g_thread_init(), you're getting
> yourself into trouble. don't do that, glib can't possibly work correctly
> in threaded scenarios without its threading system being initialized.

I know that.  Now.

What I was suggesting is that glib should try to warn the user in such
a case.

Possibly only if G_SLICE=debug-blocks is set or whatever.  It doesn't
seem all that difficult: when accessing thread specific data, compare
with the last thread id.

Miklos