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]

Getting the pipe guard


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?

Consider this patch untested at present.

L

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]