NameLost signal

[Tanu Kaskinen]

On Fri, 2013-01-25 at 10:45 +0100, Mikel Astiz wrote:
> Hi Thiago,
> 
> On Fri, Jan 25, 2013 at 9:03 AM, Thiago Macieira <thiago at kde.org> wrote:
> > On sexta-feira, 25 de janeiro de 2013 08.45.45, Mikel Astiz wrote:
> >> Hi,
> >>
> >> While debugging an issue with PulseAudio I came across an unexpected
> >> D-Bus signal.
> >>
> >> It seems that NameLost is also sent to the process voluntarily
> >> releasing a service name. Is this expected?
> >
> > Yes.
> 
> The issue we face is that the client (PulseAudio) can potentially do a
> release_name+request_name very fast (i.e. in the same event loop).
> After this a NameLost would be received and there's some ambiguity
> involved, whether it's due to the first release or whether it's a real
> NameLost.
> 
> I know the usage scenario is pretty awkward but is there any
> recommended approach to solve this? Am I missing something?
> 
> The alternatives we've thought of are:
> (1) Set a flag after release_name has succeeded, such that the next
> NameLost will be ignored.

(When Mikel says "we", I'm included in that.)

I just wanted to add that this alternative isn't as trivial as it
sounds, because what happens is that one object calls
dbus_bus_release_name(), that object is freed, and then another object
is created which adds a filter for the NameLost signal. All this happens
without returning to the main loop in between. Now the new object
receives the NameLost signal, which was caused by the previous object's
dbus_bus_release_name() call.

Changing our code is certainly an option, if libdbus doesn't and won't
provide a way to make a blocking ReleaseName call and ignore the
resulting NameLost signal.

> (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).
> (3) Add a function that would remove the NameLost from the message
> queue, to be used after dbus_bus_release_name() has succeeded (making
> the same assumption as in (2)).
> 
> Would it make sense that libdbus provides a helper function for the
> second approach? Something like dbus_bus_release_name_ignore_namelost?
> 
> Regarding (3), I can't figure out how this can be implemented with the
> currently existing API in libdbus. Would we need a new function,
> something equivalent to dbus_connection_steal_namelost?
> 
> Any other proposals?

-- 
Tanu