Re: glib memory allocation problems

> >>> 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.
> it *is* that difficult. there are a lot of things that will break if
> you expect glib to be thread safe without initializing threading.

YES I KNOW.  Telling me this any number of times won't make the issue
magically go away.

> if you can come up with a patch that catches all cases (uses of mutexes,
> conditions, private data, thread methods, ...) without impacting
> (slowing down) the common uses, please file it in our bugzilla.

Might as well direct my efforts to /dev/null, considering the apparent
clue level of certain glib developers.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]