Lev Bishop wrote:
On 7/7/06, Darryl Miles wrote:
Dave Korn wrote:
> On 07 July 2006 01:31, Darryl Miles wrote:
The underlying socket is still being used in blocking mode.
Socket?? What is this socket?
Sorry s/socket/pipe/.
Which means
when we write write 1024 bytes of data but only one PIPE buffer is free
(ulimit -p) a POSIX kernel would allow:
What is "one PIPE buffer (ulimit -p)"?
See below...
Non-blocking:
write(fd, buffer, 1024) = 512
write(fd, &buffer[512], 512) = -1 (EAGAIN)
Blocking:
write(fd, buffer, 1024) = 512
write(fd, &buffer[512], 512) = [blocking occurs until] 512
SUSv3 does not permit this behaviour. It is quite clear on this point:
"If the O_NONBLOCK flag is clear, a write request may cause the thread
to block, but on normal completion it shall return nbyte."
Okay this is fine too. I believe the applications which we are seeing
problems with are using non-blocking mode.
I would guess under WIN32 we end up with fhandler.cc:raw_write() doing:
WriteFile(hPipe, buffer, 1024, &writtenLen, 0) = [blocking occurs until]
TRUE (writtenLen=1024)
This gives the SUSv3-mandated behaviour for blocking pipes (modulo
signal-interruptibility).
For POSIX blocking mode yes of course, but for POSIX non-blocking mode
we are relying on the information coming back from
NtQueryInformationFile to indicate that our WriteFile() won't block
providing our writes are <= PIPE_BUF length.
What does "simulate 'ulimit -p'" mean? ulimit -p works just fine on cygwin:
$ ulimit -p
8
I had a complete misunderstanding on that, I was thinking the
application would tweak the kernel buffering between processes. But
this appears to be just a reporting mechanism for PIPE_BUF size at runtime.
What was the reason the existing code in CVS for select.cc was disabled?
Maybe it would help to better understand the reasons/cases where the
disabled code failed.
Darryl
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
