+++ This bug was initially created as a clone of Bug #14581 +++ Havoc wrote: > Maybe adding dbus_threads_has_recursive_mutex() makes sense, though it would > just be a nice thing for anyone installing their own thread functions, which is > probably nobody. > > Otherwise we can just assume dbus_threads_init_default() was used and that it > has recursive mutexes, so just remove the limitation on dbus-glib mainloop > source (assuming things work if you do so, I haven't tested it or anything). However, the Windows threading implementation doesn't yet have recursive mutexes (Bug #36204), so dbus-glib ought to check. Patch on the way.
Created attachment 45576 [details] [review] add API to check whether mutexes are going to be recursive dbus-glib could use this to solve Bug #14581. (Untested, but trivial.)
Doesn't GThread with recursive mutexes just work on windows anyhow? maybe the winthread stuff inside libdbus shouldn't be used, esp. if nobody is fixing it.
(In reply to comment #2) > Doesn't GThread with recursive mutexes just work on windows anyhow? We haven't used GThread for quite a long time; dbus-glib just uses dbus_threads_init_default(). D-Bus for Windows has its own mutex/etc. functions, and D-Bus for Unix uses simple wrappers around pthread similar to the ones in GLib. When dbus-glib did have its own threading primitives implemented in terms of GLib, they weren't marked as recursive, although that might be because marking them as recursive hadn't been invented yet.
(In reply to comment #1) > add API to check whether mutexes are going to be recursive Unnecessary since 1.5.10, where we require recursive mutexes and use them for most things.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.