Early Win32 code available (was: Bug in _dbus_poll() without HAVE_POLL?)

Tor Lillqvist tml@iki.fi
Fri Jan 21 07:51:30 PST 2005


Havoc Pennington writes:
 > I don't see it. Computers are so unreliable! ;-)

Apparently...

Oh well, what I said was that yes, using a copy of each DBusPollFD was
a bug was only *after* the select() call.

About dbus-spawn.c: That file is in fact the only one I didn't even
try to handle with ifdefs, it is so totally Unix specific with all the
forking. In my dbus-spawn-win32.c I just create a thread that call
spawnv() to start the child process. It uses a socketpair "pipe" so
that one can poll for the finishing of the process, like in the Unix
implementation.

The child_setup functionality is problematic. Without fork() such a
function has to be run in the main process itself, which of course
might have odd consequences. But as the only use for the child_setup
in D-BUS currently is to modify the child's environment variables,
that can then be handled more portably by creating a copy of _environ,
and modifying that, then passing that as a (new) argument to
_dbus_spawn_async_with_babysitter(), which passes the new environment
to execve() or spawnve(). See the diff of bus/activation.c.

Anyway, both dbus-test and bus-test now seem to run fine for me on
Windows, except for the GetConnectionUnixUser test that doesn't work
for some reason. Also there is one memleak from the last test...

I am also able to start dbus-daemon, dbus-monitor, and run dbus-send
and notice that they all in fact talk to each others. Can't say yet
whether they understand what they are trying to say to each others,
though...

A current diff is available at www.iki.fi/tml/dbus.my-diffs.20050121
but as there are a couple of new files that aren't in the diff, I also
did "make distdir" and made a zip archive, at
www.iki.fi/tml/dbus-0.23-win32-20050121.zip.

Obviously there is still much to do, some of the ifdeffing could in
fact (as Havoc said earlier) be replaced by suitable abstractification
on all platforms, and there are overly verbose _dbus_verbose() calls
here and there that need to be purged eventually, etc. But anyway, if
anybody is interested, please have a look.

--tml




More information about the dbus mailing list