On 7/7/06, Darryl Miles wrote:
Dave Korn wrote:
> On 07 July 2006 01:31, Darryl Miles wrote:
>> Maybe you are in a better position to share more insight into the
>> situation (specifically about the use of NtQueryInformationFile in
>> addressing the writability semantics of the POSIX select/poll/write
>> event system).
>
> I think you should just use it and it should just work.
Okay the immediate red flag I can see with it:
else if (fpli.WriteQuotaAvailable >= PIPE_BUF)
gotone += s->write_ready = true;
The underlying socket is still being used in blocking mode.
Socket?? What is this socket?
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)"?
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."
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).
Maybe PIPE_NOWAIT would be good for us (to setup when the fd has
O_NONBLOCK set).
If PIPE_NOWAIT isn't good for us. We can get around this by using
Overlapping I/O and controlling the outstanding pipe buffers. This
makes cygwin simulate 'ulimit -p' to some degree. Which is back towards
my proposal.
What does "simulate 'ulimit -p'" mean? ulimit -p works just fine on cygwin:
$ ulimit -p
8
Lev
--
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/
