NameLost signal

[Simon McVittie]

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.

Strictly speaking, dbus_bus_release_name() should probably have been
called dbus_bus_release_name_and_block(). It's just a simple wrapper
around dbus_connection_send_with_reply_and_block(); it doesn't do
anything "magic".

In my opinion, GDBus has a better API for this stuff
(g_bus_own_name_on_connection() and g_bus_unown_name()) - it would be
possible to implement something similar in terms of libdbus if you're
particularly attached to libdbus.

Regards,
    S