what's left for merging windbus
Havoc Pennington
hp at redhat.com
Fri Aug 17 08:31:53 PDT 2007
Hi,
(continuing some private discussion of what's left to merge windbus here)
Looking at what's left in dbus-win.patch, most of it seems to be
commenting out tests that should pass, and other small changes that
don't make a lot of sense to me. Maybe someone can explain those changes
one by one.
The substantive change I see is the daemon init/release stuff. This is
intended to create a singleton session bus instance per-user, right?
(per-user is probably the right scope for the session bus on Windows?)
Here are some partial comments on that.
- GetUserName() is called inside _dbus_assert; asserts can be disabled,
so code in the assert cannot have side effects.
- _dbus_daemon_init is called from listen_tcp_socket, this is the wrong
place in the code, since a tcp socket may have nothing to do with the
session bus. There are two resulting problems:
- non-session-bus may claim the mutex
- the address is not the right one; we should be advertising the
constructed address with guid in it, from
bus_context_get_address(), available only at a higher layer
- what happens if the daemon crashes without _dbus_daemon_release?
I would suggest making this work parallel to the <pidfile> construct
currently used in system.conf.
In other words, add something like this in session.conf:
<windows_mutex>DBusSession</windows_mutex>
This would imply that the bus defined by session.conf will own the mutex
"DBusSession:Daemon:username" or something, and that it will read shared
memory "DBusSession:Address:username" or something to get the address of
the session bus. Feel free to ignore the details but you get the idea.
The mutex name would still have to be hardcoded on the client side ...
this is the same problem we have where the system bus socket is
hardcoded on the client side. We may have to fix this later by parsing
the config file from libdbus or something.
For now I think it's fine to hardcode the name on the client side.
The right place to acquire the mutex and shared mem in the daemon is
probably near the end of bus_context_new() where the pidfile is acquired
(see dbus_become_daemon call there).
I would add a
dbus_bool_t
_dbus_acquire_user_mutex(const char *mutex_name,
const char *address,
DBusError **error);
on UNIX this should always fail and set an error, so if someone
specifies a <windows_mutex> in the config file on UNIX, it will never be
acquired.
Havoc
More information about the dbus
mailing list