dbus_g_thread_init()

[Havoc Pennington]

John (J5) Palmieri wrote:
> While your frustration is understandable your solution is not well
> thought out.  Part of the problem is documentation which we do need to 
> work on.  The real solution here is making threading evident to even
> those who don't use it but may in the future.  I got a lot of pushback
> from suggesting we turn on threads full time.  And no it was not from
> zealots.

Did they know about dbus_thread_disable() or whatever that was also in 
alex's patch? (btw that patch is still outstanding, is it blocking on me 
in some way?)

What were the objections?

> The idea is to have a public dbus_g_init(gboolean is_threaded) function.
> Most libraries have an init function so this is fine and we need it
> anyway since the type system is currently initialized by dbus_g_bus_get
> and there are instances where you need to use dbus types before you get
> a connection.

I think this is kind of a downgrade; init functions are in general evil 
(I consider g_type_init() a design bug)

The thread init function exists for only two reasons:
  - possible performance concerns
  - dbus not having built-in thread primitives, so someone had to
    provide the glib or qt ones

But it's deliberately an init function only for threading; there's 
deliberately no generic dbus_init.

Havoc