Bug 15686 – GtkLauncher aborts on launch due to uninitialized threading subsystem

• Component: WebKitGTK
• Status: RESOLVED FIXED

[m. dietrich]

initialization fails with the message:

GLib-ERROR **: The thread system is not yet initialized. aborting...

glib's threading must be initilized before database stuff is initialized. i put 

if (!g_thread_supported ()) g_thread_init (NULL);

into WebKitTools/GtkLauncher/main.cpp but maybe  webkit_init() in WebKit/gtk/Api/webkitgtkglobal.cpp is a better place.

[Mark Rowe (bdash)]

What is happening here is that webkit_init calls DatabaseTracker::tracker to retrieve the DatabaseTracker singleton to set the database path.  The DatabaseTracker constructor allocates a SQLDatabase, which in turn allocates a Mutex.  All of this happens without WebCore calling initializeThreading.  The Gtk port could work around this by calling initializeThreading from webkit_init, but WebCore should be doing this itself before doing anything thread-related (this includes allocating mutexes).

[Mark Rowe (bdash)]

Copying Brady as he's done a lot of the work on the threading support in WebCore.  Brady, do you have any idea how to ensure that initializeThreading is always called at the appropriate times?  The two locations that it is currently called from seem quite arbitrary.

[Alp Toker]

Database support has been disabled in r27047 pending a fix for this bug. GtkLauncher should work again.

[Brady Eidson]

Actually, there's already an abstraction for this in WebCore.  Check out threading.h - 

void initializeThreading();

It seems that GTK already hooked into that in r26864

initializeThreading() is called at any point a secondary thread might be kicked off.  Currently this include the IconDatabase c'tor and the Database c'tor.  GTK's impl in ThreadingGTK.cpp seems to do exactly what you say needs to be done -
if (!g_thread_supported ()) g_thread_init (NULL);

So in other words, I'm surprised this isn't working already.

[Brady Eidson]

Per Mark's comment of "the two locations now seem quite arbritrary" - perhaps the specific locations can be tweaked somewhat, but I like the idea of initializing threading *only* when a secondary thread might be kicked off.

If a client doesn't use the icon database and never visits a page with client-side databases, there's no reason they should init threading

[Alp Toker]

Created attachment 16861 [details]
Fix, initialize thread support early as possible

[Brady Eidson]

Comment on attachment 16861 [details]
Fix, initialize thread support early as possible

I'm still curious why the initialize-on-the-spot didn't work, but this seems reasonable.

[Alp Toker]

Fixed in r27050.