GBus discussion
Fan Wu
wufan9418 at gmail.com
Fri Aug 17 10:03:37 PDT 2007
HI Havoc,
some comments/questions on GBus. I know it's a sketch at this time,
but let's start polishing it.
- The target
Just to make sure I understand it correctly, the eventual goals of gbus are:
* a thin wrapper of libdbus API which is shipped as part of libdbus
* no dependency on glib
* agnostic to looping mechanism (works with both thread and mainloop)
For the last bullet I don't mean providing support for both thread and
mainloop, but the opposite, leave that part to user (see commnets on
"ConnectionTracker" below).
- thread safety
We probably need a mutex to guard access to helper. Should all
GBusName and GBusNameOwner be refcounted? I'm thinking a thread is
running a filter registered for name tracking, while user calls from
another thread to unregister the name tracker.
- ConnectionTracker
Connection tracker is different from name tracker and owner tracker in
that name/owner tracker are registered with an established Dbus
connection. But the connection does not exist when
gbus_register_connection_tracker() is called. The current
implemenation registers the connection tracker and a callback
(try_to_connect_idle) with the event loop of glib. If we want to stay
away from glib while makes the wrapper loop-agnostic, one possible way
is to make the try_to_connect function part of the API, and let user's
code call it directly from their own mainloop/thread. The function
try_to_connect() will set up the connection (retry if necessary), call
the Connected callback when the connection is up, and before it exits
it sets up a filter watching for the Disconnected message. With all
these tasks done by try_to_connect(), do we still need
gbus_register_connection_tracker() and
gbus_unregister_connection_tracker() at all?
- Single instance
What is the definition of single instanace? My interpretation is "my
application is the primary owner of the specific name". If this is
correct then the mapping between GBusNameOwnershipStyle and owner
flags would be like:
GBUS_NAME_SINGLE_INSTANCE_REPLACING_CURRENT_OWNER =
DBUS_NAME_FLAG_REPLACE_EXISTING
GBUS_NAME_SINGLE_INSTANCE = 0
GBUS_NAME_OWNED_OPTIONALLY = DBUS_NAME_FLAG_DO_NOT_QUEUE |
DBUS_NAME_FLAG_ALLOW_REPLACEMENT
Is it correct?
- Owner tracker
Right now owner tracker has two handlers: owned_handler and
not_owned_handler. When a request is made on a name there could be
error or one of the following results:
DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER
DBUS_REQUEST_NAME_REPLY_IN_QUEUE
DBUS_REQUEST_NAME_REPLY_EXISTS
DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER
One of the questions is, if the result is ALREADY_OWNER, shall we
still call owned_handler?
Also in what condition shall we call not_owned_handler? When failed to
acquired a name, or ONLY when NameLost is received?
We can probably simplify things a bit by specifying not_owned_handler
is to handle NameLost, while all the other cases are handled by
owned_handler, which will require owned_handler be able to take more
parameters like the return code and the error message.
Another way is to add another handler: failed_to_own_handler which
handles error conditions and if return code being one of
IN_QUEUE/EXITS/ALREADY_OWNER. And owned_handler is exclusively for
PRIMARY_OWNER, and not_owned_handler for NameLost (probably we shall
name it name_lost_handler.
- gbus_unregister_name_owner
gbus_unregister_name_owner (DBusConnection *connection,
const char *owned_name,
const GBusNameOwner *owner,
void *data)
The question is why owner and data info is supplied again? Is there
consideration that owner/data might be different from the call to
register the name owner?
Thanks,
Fan
More information about the dbus
mailing list