[announce] dbus4win

[Thiago Macieira]

Em Terça-feira 21 Abril 2009, às 16:32:15, Tor Lillqvist escreveu:
> My guess is that a Windows equivalent to Unix domain sockets would be
> named pipes? (Should not be confused with Unix named pipes; Only the
> name is the same.)

That's what we used for the Windows version of QLocalSocket 
(http://doc.trolltech.com/4.5/qlocalsocket.html), but now that we have used 
it, I wouldn't recommend it for D-Bus.

First of all, they're a bit slow. We have an open suggestion in our task 
tracker system to replace the backend with completion ports. I have not yet 
investigated what those things are, so I can't comment on them, except that 
the person who made the suggestion thinks they're faster.

Second, named pipes on Windows are very hard to use. Named pipes use a 
separate namespace on the filesystem hierarchy than files. And unlike a TCP 
server socket or Unix server socket, one file descriptor cannot accept multiple 
connections. Instead, the daemon must create a series of backup pipes with the 
same name. That's not such a big problem, if you consider the "backlog" 
argument to listen(2).

But named pipes only get worse: Windows doesn't have the concept of non-
blocking calls like Unix does (except for sockets, which are technically 
imported from BSD). The "overlapped" concept is similar, but not exactly. And 
to make matters worse, you can't get a notification that the HANDLE is ready to 
write: so you need to keep a thread running that constantly tries to write.

And if you're not satisfied, then here's one more: named pipes are not 
available on Windows CE. So the Windows CE version of QLocalSocket uses... 
TCP/IP :-)
[So I would actually go as far as implement the nonce+TCP/IP suggestion as a 
fallback for QLocalSocket itself, to match what D-Bus and libassuan do.]

Of course, then you enter a whole new world of problems, because the WinSock 
API is full of holes, bugs and incompatibilities...

I don't envy the KDAB developers here.

> Unfortunately I have never coded anything with named pipes, so I can't
> say how hard or easy it is to use them in software that otherwise is
> loosely Unixish in style.
>
> I agree with Havoc that dbus on Windows should not try to use Unix
> concepts where it isn't natural.

Let's be frank: D-Bus was written on Unix and it has Unix in mind. It's only 
natural that it uses Unix concepts.

Trying to map to Windows concepts will not work in all cases. I do agree with 
Havoc that we shouldn't use Unix emulation layers, but also going full Windows 
will be more trouble than it's worth. It would also make code maintenance a 
lot more difficult (more than it will be) because of the differing code paths.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090421/3b653d9e/attachment-0001.pgp