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