On Tue, 14 Sep 2021 11:03:39 +0200
Corinna Vinschen wrote:
> On Sep 14 17:08, Takashi Yano wrote:
> > @@ -54,8 +54,12 @@ fhandler_pipe::set_pipe_non_blocking (bool nonblocking)
> >    FILE_PIPE_INFORMATION fpi;
> >  
> >    fpi.ReadMode = FILE_PIPE_BYTE_STREAM_MODE;
> > -  fpi.CompletionMode = nonblocking ? FILE_PIPE_COMPLETE_OPERATION
> > -    : FILE_PIPE_QUEUE_OPERATION;
> > +  /* If query_hdl is set, write pipe should check reader_closed()
> > +     while raw_read(). If the pipe is blocking, raw_write() stops
> > +     at NtWriteFile() and loses the chance to check it. Therefore,
> > +     always set write pipe to non-blocking. */
> > +  fpi.CompletionMode = (nonblocking || query_hdl)
> > +    ? FILE_PIPE_COMPLETE_OPERATION : FILE_PIPE_QUEUE_OPERATION;
> >    status = NtSetInformationFile (get_handle (), &io, &fpi, sizeof fpi,
> >  				 FilePipeInformation);
> >    if (!NT_SUCCESS (status))
> 
> I don't quite follow the argument.  Blocking pipes are using
> asynchronous IO, so they are in fact not blocking calls on the
> OS level.  After calling NtWriteFile, the blocking variation
> will go into the subsequent
> 
>   waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
> 
> So, wouldn't you get the same effect by keeping the pipe in
> FILE_PIPE_QUEUE_OPERATION mode and just add a timeout to the above
> cygwait call and handle select_sem in a not yet existing WAIT_TIMEOUT
> conditional?

Sounds reasonable. I revised the patches. Do you mean something like
patch attached?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>