[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-blocking I/O on Woe32
From: |
Bruno Haible |
Subject: |
Re: non-blocking I/O on Woe32 |
Date: |
Tue, 29 Mar 2011 16:16:03 +0100 |
User-agent: |
KMail/1.9.9 |
Eric Blake wrote:
> Mingw has named pipes, but they appear to
> reside in a different namespace than the normal file system, and the
> gnulib mkfifo() implementation current always fails with ENOSYS on
> mingw. Unless we find a way to expose named pipes in the normal file
> system on mingw, then you are right that there's no work to do for
> O_NONBLOCK on any file that mingw can open.
More precisely the named pipes reside in a special portion of the file system.
See [1][2][3].
When run I a program that calls
CreateNamedPipe ("\\\\.\\pipe\\foo", PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE,
3, 512, 512, 0, NULL)
and then sleeps, and while the program sleeps, I run a cmd.exe with
type \\.\pipe\foo
then it finds the pipe and tries to read from it. But as soon as the creator
process is terminated, the pipe is closed and disappears from the file system.
[4]
So it's OK to leave gnulib's mkfifo() as it as, because on Windows, a program
like 'mkfifo' that terminates immediately after creating a named pipe would
be useless.
Bruno
[1] http://msdn.microsoft.com/en-us/library/aa365137.aspx
[2] http://msdn.microsoft.com/en-us/library/aa365783.aspx
[3] http://msdn.microsoft.com/en-us/library/aa365150.aspx
[4] http://en.wikipedia.org/wiki/Named_pipe#Named_pipes_in_Windows
--
In memoriam Rachel Levy <http://en.wikipedia.org/wiki/Rachel_Levy>
- Re: [libvirt] mingw: virsh event loop failure in current git, Eric Blake, 2011/03/28
- Re: non-blocking I/O, Bruno Haible, 2011/03/29
- Re: non-blocking I/O, Eric Blake, 2011/03/30
- Re: non-blocking I/O, Eric Blake, 2011/03/30
- Re: non-blocking I/O, Paolo Bonzini, 2011/03/31
- Re: non-blocking I/O, Bruno Haible, 2011/03/31
- [PATCH] nonblocking: new module, Eric Blake, 2011/03/31