NameLost signal

[Mikel Astiz]

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.
(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?

Cheers,
Mikel