On 9/6/2021 8:49 AM, Corinna Vinschen wrote:
> - I think setting chunk to DEFAULT_PIPEBUFSIZE - 1 in the read case and
>    DEFAULT_PIPEBUFSIZE in the write case by default is dangerous.
>    Assuming the pipe has been created by a non-Cygwin process, the values
>    may be way too high.
> 
>    Suggestion: Actually set max_atomic_write to something useful.
>    Set max_atomic_write to DEFAULT_PIPEBUFSIZE in fhandler_pipe::create.
>    In case of stdio handles inherited from non-Cygwin processes, fetch
>    the pipe buffer size via NtQueryInformationFile in
>    dtable::init_std_file_from_handle().  Better, in a matching
>    fhandler_pipe method called from init_std_file_from_handle().

How about something like the attached (untested)?

> - What about calling select for writing on pipes read by non-Cygwin
>    processes?  In that case, we still can't rely on WriteQuotaAvailable,
>    just as before.
> 
>    I have a vague idea that we might want to count readers in that case,
>    but I have to think about it some more.

Even if we count readers, we have no way of knowing whether a pending read has 
reduced WriteQuotaAvailable to 0.  Maybe this is a case where we should impose 
some artificial timeout, after which we report write ready.  Falsely reporting 
write ready in this corner case seems better than risking a deadlock.

Ken