thiago at kde.org
Tue Apr 21 09:33:35 PDT 2009
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...
[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
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090421/3b653d9e/attachment-0001.pgp
More information about the dbus