GBus discussion

[Fan Wu]

HI Havoc,

thanks again for the explanation!

Let me summarize our discussion on this specific issue: whether or not
the error (DBusError) or certain return codes shall be passed to the
not_owned or unavailable callback.

Your opinion is this is not necessary since all that an application
needs to know is the result (owned or not-owned, available or
unavailable),  and application shall maintain an internal state so as
to act to the result accordingly. In the case of error conditions, a
callback like UnexpectedErrorHandler can be set to retrieve related
information. If error conditions are used to influence the flow of the
application, the not_owned or unavailable handler shall check the last
error and see if it matters.

My concerns for this approach are:

- you provided quite some sample code on how the tri-state (unknown,
owned, not owned) works (thanks!), and it does make sense, but the
question is will it be enough to cover all use cases? For example, the
name could be lost either by someone replaced us, or there is a
problem with the connection. And users might take different actions in
the not_owned handler. This might be a bad example, but I just do not
want to eliminate the possibility that  developers want to have access
to the details.

- The UnexpectedErrorHandler callback can be used to make up for the
situation above, but  now we need to consider possible racing
conditions: after UnexpectedErrorHandler is called  but before
not_owned/unavailable handler retrieves the last error, another thread
might initiate something which called UnexpectedErrorHandler and adds
another error...  to solve the problem we can have lock or  have a
FIFO to store the errors and have the handler claims and clears the
corresponding errors. But these just add to the complexity.

So I'd still prefer just passing the all the info directly to
callback, if just to save people coming back and asking for it.

Thanks,
Fan

On 8/18/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> On 8/18/07, Fan Wu <wufan9418 at gmail.com> wrote:
> > Sorry I didn't make myself clear when referring to "error message".
> > What I meant was DBusError which I think include both the error
> > DBusMessages and the errors set by the libdbus (reply timeout, or bad
> > DBusMessage etc), and pass the DBusError to the callbacks.
> >
>
> For requesting a name, a DBusError is effectively impossible unless
> there's a bug in the bus, or the connection disconnects.
>
> For disconnect I think calling the "not owned" callback and then
> calling a disconnect callback is appropriate; this should not be
> treated as an error but just as a disconnect.
>
> For a bug in the bus, I would say just printing a warning in the
> library itself is fine (probably with some way for apps to override
> the warning handler).
>
> typedef void (* GBusUnexpectedErrorHandler) (const DBusError *error,
> const char *context_description, void *data);
>
> gbus_set_unexpected_error_handler(GBusUnexpectedErrorHandler handler,
> void *data);
>
> static void
> default_unexpected_error_handler(const DBusError *error, const char
> *context_description, void *data)
> {
>   _dbus_warn("%s: did not expect error %s: %s\n", context_description,
> error->name, error->message);
> }
>
> So then when doing the request name (note that dbus_bus_request_name
> blocks so should not be used, we'd do it async):
>
>  old_state = OWNED, NOT_OWNED, or UNKNOWN;
>
>  if (dbus_message_is_error(reply))
>    {
>       // an error is expected if we were disconnected, so don't warn
>       if (dbus_connection_get_is_connected(connection))
>           run_unexpected_error_handler_for_message(reply, "requesting
> a bus name");
>       new_state = NOT_OWNED;
>    }
>  else
>    {
>       new_state = OWNED or NOT_OWNED depending on reply;
>    }
>
>     if (new_state == OWNED && new_state != old_state)
>       invoke_owned_callback()
>     else if (new_state == NOT_OWNED && new_state != old_state)
>       invoke_not_owned_callback();
>
> Something like that...
>
> Havoc
>