mikel.astiz.oss at gmail.com
Fri Jan 25 01:45:54 PST 2013
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:
>> 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?
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
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?
More information about the dbus