On Apr 29 18:42, Ken Brown wrote: > On 4/29/2019 2:29 PM, Ken Brown wrote: > > On 3/25/2019 7:06 PM, Ken Brown wrote: > >> The second patch in this series enables opening a FIFO with O_RDWR > >> access. The underlying Windows named pipe is created with duplex > >> access, and its handle is made the I/O handle of the first client. > >> > >> I tested the patch in two ways. > >> > >> First, > > > > [...] > > > >> The second test was the following sequence of commands in a bash > >> shell: > >> > >> $ mkfifo foo > >> > >> $ exec 7<>foo > >> > >> $ echo blah > foo > >> > >> $ read bar <&7 > >> > >> $ echo $bar > >> blah > > > > I just realized that this doesn't test *writing* to the fd of a FIFO > > opened with O_RDWR. If I change the third command to "echo blah > > >&7", it does test this, and the write fails with ECOMM. It turns > > >out that the call to NtWriteFile in fhandler_fifo::raw_write fails > > >with STATUS_PIPE_LISTENING. > > > > Corinna, I'll try to debug this, but since I know you're about to be > > AFK for a month, I thought I'd check to see if you have any idea why > > this would happen. > > Actually, the answer might be obvious. Looking at MSDN, it now seems > clear to me that you can't do I/O on the server side of a pipe until > the pipe connects to a client. So I'll have to rethink how to deal > with the O_RDWR case.
Sorry being late, but yeah, STATUS_PIPE_LISTENING means no client is connected. This is one of the more ugly implementation details of Windows pipes. There just isn't a generic buffer which can be filled even if no one is listening yet on the other side :-P Corinna -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature
