Bug in _dbus_poll() without HAVE_POLL?

[Tor Lillqvist]

 >  > Looks sensible, please commit. (Now we know that nobody has ever used
 >  > dbus on a platform without poll I guess.)

BTW, I seem to be momentarily stuck now in my Win32 port, for some
reason bus-test gets stuck after a while in a call to _dbus_poll with
timeout of -1. select() never returns. (And no, just adding a hack to
set the timeout to, say, one second instead, doesn't help either. It
just then loops through a bit wider code path but always comes back to
_dbus_poll(), and never finds any socket readable. Earlier calls with
timeout -1 don't hang, but a certain one always does. It's at the
GetConnectionUnixUser exchange.)

I assume this is due to some Win32 specific problem and not
generic. But to verify, could somebody please try and manually
undefine HAVE_POLL in their config.h on some Unix box, build dbus, and
run bus-test? (Remember to first fix the two obvious bugs I mentioned
earlier in this thread in the non-HAVE_POLL part of _dbus_poll().)

One reason for the hang might be a deadlock. A process talking with
itself through a pipe (or socket pair) as bus-test does is always
risky. In my Win32 port, uids are in fact strings (string
representation of SID, like "S-1-5-21-1220945662-769437303-893522151-1000"). 
I.e. clearly longer that the 32-bit-int uids used on Unix. If WinSock
uses unusually small buffers by default or something, couldn't it be
possible that the stuff bus-test tries to write to itself through the
debug-pipe (socketpair) is just a bit too long, so that it hasn't been
able to write everything before it tries to read it all, or
something. Does this sound like a possible scenario?

--tml