Mail Archives: cygwin/2006/07/07/00:17:43
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. Which means
when we write write 1024 bytes of data but only one PIPE buffer is free
(ulimit -p) a POSIX kernel would allow:
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
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)
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.
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/
- Raw text -