Re: Review of gnio, round 1

On Mon, 2009-04-27 at 23:32 +0300, Tor Lillqvist wrote:
> > I remember reading recently that there was all kinds of issues with
> > local pipes on win32, but I don't remember any details. It was on some
> > gnome list, maybe even this.
> It was on the dbus list. Quoting myself and 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.)
> 2009/4/21 Thiago Macieira <thiago kde org>:
> > That's what we used for the Windows version of QLocalSocket
> > (, 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.

Hmm, this makes them quite tricky to integrate with GSocket and the rest
of gnio, so they don't seem very interesting...

> 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.

So, maybe we should actually have the win32 version of a "abstract local
socket" just use a loopback interface tcp connection...

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]