NameLost signal

[Tanu Kaskinen]

On Fri, 2013-01-25 at 12:56 +0000, Simon McVittie wrote:
> On 25/01/13 09:45, Mikel Astiz wrote:
> > (2) Implement a new function similar to dbus_bus_release_name() which
> > ignores the NameLost immediately before the reply to ReleaseName has
> > been received (assuming that NameLost is guaranteed to be received
> > before the reply to ReleaseName).
> 
> It sounds as though the problem is that you're making a
> "pseudo-blocking" D-Bus method call, which results in its reply being
> processed before any signals (or other messages) that actually happened
> before the reply.
> 
> See <http://smcv.pseudorandom.co.uk/2008/11/nonblocking/> for more on
> why not to do that.
> 
> I would suggest keeping track of what names you currently believe you
> own, using NameAcquired and NameLost to keep it up-to-date; then if you
> already own a name N but are in the process of releasing it, use your
> main loop (you do have a main loop, right?) to defer creation of a
> second object that wants name N until you no longer own it.
> 
> Ideally, release N using an asynchronous call (compose a ReleaseName
> message with dbus_message_new_method_call() and send it with
> dbus_connection_send_with_reply()) rather than using
> dbus_bus_release_name(), so that you won't get confused about the order
> of events. If you avoid blocking on method calls, messages get delivered
> in the right order and everything is easier to understand.

Thank you for the advice. I agree that it's best to avoid blocking D-Bus
calls. In this case, however, I don't think we're going to change to
asynchronous name acquiring and releasing. It's done when pulseaudio
opens or closes a sound card, and those operations are synchronous. They
shouldn't be, but changing it at this point is more work than what I'm
willing to do just to fix the bug that is caused by the unexpected
NameLost signal.

I think we will, as a quick and dirty fix, switch to private D-Bus
connections with these problematic objects. That should prevent the
NameLost signal leaking from one object to the next. I hope a better fix
will happen eventually...

-- 
Tanu