Summary: | GtkLauncher aborts on launch due to uninitialized threading subsystem | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | m. dietrich <mdt> | ||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | beidson, mrowe | ||||
Priority: | P2 | ||||||
Version: | 523.x (Safari 3) | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
m. dietrich
2007-10-25 05:53:23 PDT
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). 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. Database support has been disabled in r27047 pending a fix for this bug. GtkLauncher should work again. 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. 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 Created attachment 16861 [details]
Fix, initialize thread support early as possible
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.
|