Re: bugs regarding late g_thread_init() calls

Torsten Schoenfeld wrote:
    if (!g_thread_supported ())
        g_thread_init (NULL);

bzzzzz!  g_thread_supported called too early.

g_thread_supported is actually a macro.  It's another name for
g_threads_got_initialized basically.  So the idiom above should be safe,

Just $.02, but does this mean that a programmer need to be an expert in the status of each symbol just to initialize a program properly? It seems to me that there is an evolution here from glib being a library that works readily without threads to one that usually assumes that threads are going to be initialized and probably used. I don't know what that means in terms of api, but it might help to explicitly note that this is a change.

One more thing -- isn't there a binary compatibility issue here? If a program worked with 2.6, doesn't it need to work with new releases without recompilation in order for binary compatibility to be preserved?



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