[PATCH] Privatize the DBusPendingCall struct

[Havoc Pennington]

Thiago Macieira wrote:
> 
> Since this is called from dbus_connection_send_with_reply (indirectly, 
> through _dbus_pending_call_new), the connection is locked twice and the 
> program, thus, deadlocks.
> 
> Are mutexes now required to be recursive?

Nope, I'd consider this a bug. John's patch was only half the solution; 
it ensures that pending->connection is always a live object, but now 
there's another step which is to always hold the connection lock inside 
the methods on pending call. (and drop the connection lock or use 
"unlocked" functions when appropriate, as dbus-connection itself does)

It's possible all pending call internal methods should end in either 
_locked, _unlocked, or _and_unlock to be clear about their locking behavior.

The solution to this specific bug seems to be that pending_call_new 
should assume the connection is already locked, so:

  _dbus_pending_call_new_unlocked(connection) {
      _dbus_connection_ref_unlocked(connection);
  }


Havoc