> On Sat, Aug 20, 2011 at 6:00 PM, Yehouda Harpaz <y...@lispworks.com> wrote: > >> > http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness > > > > I read this and it didn't tell me anything that I don't already know, > > and didn't answer the original question (what supposed to hold the GDK > > lock in calls from WebKit/gtk/WebCoreSupport). > > If you are calling GTK+ from threads other than the main one you are > the one supposed to lock things properly . Most (all?) GTK+-ish > libraries are at best thread-aware, so they don't automatically lock > every single GDK/GTK+ function call they make except for things in > timeouts/idle handlers (since they are executed outside of the GTK+ > main lock). >
We do lock allour calls, but WebKitGTK doesn't, and that is the problem. The backtrace in the original message shows that. Maybe it is assumed that there will a lock around, but I don't see where. Since it is called from Soup code that is itself called from g_main_dispatch, there cannot be a lock at that point. And I don't anyting inside that tries to look. Can anybody in this list look at the actual and answer the actual question? Or do I need to send it to anther place? _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
