Ramp up to D-Bus 0.90

[Havoc Pennington]

John (J5) Palmieri wrote:
> 
>  - add a new return code from dbus_connection_dispatch() called 
>    IN_PROGRESS or RECURSED or something, indicating that DATA_REMAINS
>    but another dispatch is in progress, so we can't dispatch at 
>    this time. OR maybe just switch to recursive locks for the dispatch 
>    locks. Fixes the recursive deadlock. See the @todo for more
>    and this thread:
> http://lists.freedesktop.org/archives/dbus/2006-February/004128.html
> 
> Is this important for 1.0?  Right now I think we decided for the
> bindings to work around this issue.

It might be nice if we could throw a warning if apps use the broken 
codepath - don't know if we really can though.

It could also be worth just adding recursive locks to the dbus threads 
init, so bindings start providing those, then we could maybe fix this 
without any breakage.

> ====================================================================
> 
>  - Audit @todo and FIXME for security issues
> 
> 0.90-1.0 timeframe

It might not be a disaster to scan these for stuff that could involve an 
API change.

> ====================================================================
> 
>  - the "break loader" and valid/invalid message tests are all disabled;
>    they need to be fixed and re-enabled with the new message args stuff.
>    I think I want to drop the .message files thing and just have code
>    that generates messages, more like the tests for
>    dbus-marshal-recursive.c (this is mostly done now, just needs some
>    cleanup)
> 
> Remove this for 1.0 or leave this for 0.90-1.0 timeframe?  Test coverage
> is already very good and we have been running without these tests for
> awhile now.

This is very unlikely to create an API change, so I don't think it's a 
blocker.

> ====================================================================
> 
>  - dbus-pending-call.c has some API and thread safety issues to review.
>    DBusPendingCall is used from multiple threads with no locks.
>    Either DBusConnection's lock has to protect all associated pending
>    call (means pending->connection can't ever be set to null) or 
>    or DBusPendingCall needs its own lock
>    http://lists.freedesktop.org/archives/dbus/2006-June/004945.html
> 
> I'm working on this.

Cool this is the main one I was worried about.

> ====================================================================
>  
>  - RequestName flags seem a bit strange; see the docs for
> dbus_bus_request_name() 
>    and think about use cases in better detail. 
>    Proposal on list:
>    http://lists.freedesktop.org/archives/dbus/2005-August/003207.html
> 
>    Kind of a major API change, but seems high-value.
> 
> This was done with no complaints.  We have been using the new system
> since 0.60.  Time to move on and accept what we have.

This was fixed and just not removed from TODO right?

> ====================================================================
> 
>  - dbus_bus_get() should hold a strong reference associated with the
> "connected" 
>    state (i.e. libdbus drops its reference when the connection
> disconnects,
>    and sets its internal connection variable to null).
>    See http://lists.freedesktop.org/archives/dbus/2006-May/004806.html
> 
> Patch attached

Shouldn't this patch unref on disconnect? Or was code to do that already 
present?

Havoc