This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I was trying to make nonblocking pipe reads actually not block. Here's an example of the problem:
bash-3.1$ exec 8< <(while :; do sleep 1 ; echo -n \* ; done ) bash-3.1$ cat <&8 >/dev/null & [2] 308 bash-3.1$ dd iflag=nonblock bs=1 <&8 dd: reading `standard input': Resource temporarily unavailable 0+0 records in 0+0 records out 0 bytes (0 B) copied, 3.2 seconds, 0.0 kB/s
I tracked down the problem and made the attached patch to get the guard mutex, which I believe was cgf's intention when he put get_guard (I'm guessing from the changelogs, here), since the previous code was a no-op.
2006-05-15 Lev Bishop <lev.bishop+cygwin@gmail.com> * select.cc (fhandler_pipe::ready_for_read): Actually get the guard mutex.
However, although this improves things, the "nonblocking" read can still block for the duration of one read in the other process. I deduce that, despite the msdn article on PeekNamedPipe:
The function always returns immediately, even if there is no data in the pipe. The wait mode of a named pipe handle (blocking or nonblocking) has no effect on the function.
...actually it can block for the duration of another process's blocking read. Presumably, windows has an internal guard mutex of it's own.....
There are 2 questions I have related to this: 1) Why does cygwin go to all the trouble of having guard mutexes and so on for it's pipes, to simulate nonblocking operations (imperfectly for pipe reads, not at all for pipe writes) when there's the PIPE_NOWAIT flag available which appears to do it in a built-in fashion? Has this been considered and rejected for some reason I can't think of? 2) In my example above I had 2 descriptors to the same pipe, one set blocking and one nonblocking. Unix behaviour doesn't allow this because O_NONBLOCK applies to the file description, not to a particular file descriptor. The same goes for O_APPEND, O_ASYNC, etc. For full unix compatibility these flags (and I would guess various parts of the fhandler_xxx structures, like my fhandler_socket::chunk) would have to be put in shared regions or similar. Has something like this been contemplated?
Attachment:
selectpatch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |