dbus glib win32

Peter Kümmel syntheticpp at gmx.net
Tue Dec 19 14:31:30 PST 2006

Ralf Habacker wrote:
> zaryad_mail at adelphia.net schrieb:
>> Hello folks,
>> I've built the latest windbus (0.94) with mingw, as well as the glib
>> bindings (0.72). The bindings are supposedly unsupported on win32 yet
>> after some tweaking, it builds. I made one change in
>> dbus-gmain.c->connection_setup_add_watch:
>> -  channel = g_io_channel_unix_new ( dbus_watch_get_fd (watch));
>> + channel = g_io_channel_win32_new_socket( dbus_watch_get_fd (watch));
>> Due to the former not being able to correctly disambiguate whether the
>> provided descriptor is a file or socket, subsequently returning a null
>> GIOChannel. Glib built for win32 has this function in giowin32.c, in
>> addition to the socket-specific implementation, so I chose to use the
>> socket-specific one just for testing. (since it is known that
>> descriptor is a wsa socket)
>> With this change, I observe the following:
>> Server test is able to connect to session bus, register an object,
>> request name and go into gmainloop.
>> Client test fails to dispatch a method call on the server, infact
>> monitoring the server process with DBUS_VERBOSE=1, it appears
>> that once gmainloop is invoked, no further changes occur even after a
>> client requests a method call. (not picking up data on the wire)
>> To determine whether this was fault of windbus, I tried Matthew
>> Johnson's java bindings, which worked ok.
>> Furthermore, java server object is functional to glib clients, as well
>> as java clients. However, glib server object does not work either with
>> java clients or glib clients.
>> From this I conclude that something is amiss in the glib server code,
>> for this I ask some of you to give me hints/pointers so I may better
>> spend my time finding the culprit.
>> (I presume that this may be a stall in the pull phase, somewhere the
>> socket code just faults and doesn't read anything off the wire, since
>> its clear windbus is indeed sending those requests. Java server code
>> is able to read those requests, but java code uses a threaded
>> approach, thus not exercising the same pathways as the glib dbus
>> bindings)
>> I'm new to this and am determined to fix this, glib provides nice
>> bindings, IMO it would be nice if it ran on win32 as well.
> dbus win32 encapsulates socket and file fd's into dbus specific handles,
> which has to be decapsulated when using with raw socket functions like
> select or similar. We encountered such problems with the qdbus binding
> see http://windbus.svn.sourceforge.net/viewvc/windbus?view=rev&revision=481

This patch fixes dbus_watch_get_fd in that way that you get a real fd.
I assume the 0.94 version returns our dbus specific handle which is
without use for any non-windbus functions.

> The solution is to use dbus_watch_get_handle() instead of
> dbus_watch_get_fd()

It depends what your g_io_channel_win32_new_socket function
does. Does it call other dbus functions with the fd, or does
it call win32 functions? For the dbus functions use _handle,
for win32 _fd.


More information about the dbus mailing list