[PATCH] Cygwin: pipe: Restore blocking mode of read pipe on close()

Takashi Yano takashi.yano@nifty.ne.jp
Mon Sep 2 13:50:45 GMT 2024


On Mon, 2 Sep 2024 14:48:35 +0200 (CEST)
Johannes Schindelin wrote:
> I have tested it and the symptom is addressed.

Thanks for testing.

> I do have to wonder whether it is intentional that calling
> `set_pipe_non_blocking(false)` followed by `set_pipe_non_blocking(true)`
> on an originally-non-blocking pipe will "restore" it to blocking mode,
> though.

I'm not sure how such symptom occurs.

Calling `set_pipe_non_blocking(true)` on an originally-non-blocking pipe
will set `was_blocking_read_pipe` to false.

Furthermore, regardless of the value of `was_blocking_read_pipe`, calling
set_pipe_non_blocking(false) always sets the pipe blocking mode. It is not
due to "restore" logic.

> In other words, where I would have expected undesired logic to be removed,
> or at least to be adjusted, the patch instead adds code on top, adding
> even more logic.
> 
> > I just wonder if the whole code could be simplified, if we set
> > the pipe to non-blocking only temporarily while reading or writing,
> > while the pipe is blocking all the time otherwise:
> >
> > - Create pipe blocking
> >
> > - set_pipe_non_blocking(true);
> >   NtReadFile() or NtWriteFile();
> >   set_pipe_non_blocking(false)
> >
> > How costly is it to call NtSetInformationFile(FilePipeInformation)
> > for each read/write?
> 
> That would potentially be a remedy, but I would worry that this design
> takes a decidedly single-thread world-view. While that may be appropriate
> in the context of the scenario described in the bug report, it may very
> well be inappropriate for Cygwin in general.

In the first place, it is obvious that multiple threads writing and
reading from the same pipe at the same time causes undefined behavior,
regardless of whether the pipe mode is toggled or not, isn't it?

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


More information about the Cygwin-patches mailing list