Re: When to call g_thread_init(), again...

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Fri, Aug 15, 2008 at 11:51 AM, Brian J. Tarricone <bjt23 cornell edu> wrote:
> Yes to that last bit.  If it really truly does matter that
> g_thread_init() be called before other glib functions, then no *library*
> should *ever* call g_thread_init().  If a library needs it, it should
> check g_thread_supported(), and g_error() with a useful error message
> if it fails.
>
> That way, the programmer of the app knows the first time they test-run
> their app that they've done it wrong.
>
>> So, should the requirement for g_thread_init() being called before any
>> other GLib API, if it is called at all, be removed? (After all,
>> failing it apparently is harmless anyway, on Linux.

Please, be very carefull in describing that some sunction should be
called before of any other functions from library (g_thread_init() in
this case).
It is very annoing when more than one function in library have such statement.

For example, Glib have g_mem_set_vtable() that alose requires to be first.

Current wording of the g_thread_init() documentation doesn't
introduces such ambiguility at least...

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>