Re: bugs regarding late g_thread_init() calls



>  * It does appear that we are pulling in pthread in any case for 
>    a standard GTK+ application these days, so perhaps it would
>    be worth at least considering whether we wanted to make that
>    a hard dependency; considerations:
> 
>    - What simplifications could we achieve with such a hard dependency?
>    - The only use for libgthread is to avoid a hard pthread dependency;
>      if we added such a dependency, would it make sense to make
>      libgthread an empty dummy library? (it can't be quite empty
>      on windows, since g_thread_init() has to stay in the same DLL)
>    - Could g_thread_init() be removed entirely, by making the different
>      subsystems lazily initialize themselves? What's the performance
>      impact of the necessary GOnce usage for this?
>    - What is the performance degradation when you link to -pthread?

On many unix systems, linking with -lpthread will replace many libc
calls (e.g. read, write, ...) by thread-safe versions, which are
heavier (extra use of locks).

Arno



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