Hi Corinna and Takashi,

On Mon, 2 Sep 2024, Corinna Vinschen wrote:

> On Aug 30 23:15, Takashi Yano wrote:
> > If a cygwin app is executed from a non-cygwin app and the cygwin
> > app exits, read pipe remains on non-blocking mode because of the
> > commit fc691d0246b9. Due to this behaviour, the non-cygwin app
> > cannot read the pipe correctly after that. With this patch, the
> > blocking mode of the read pipe is stored into was_blocking_read_pipe
> > on set_pipe_non_blocking() when the cygwin app starts and restored
> > on close().
>
> Looks ok to me, but it would be helpful if Johannes could test this as
> well.

I have tested it and the symptom is addressed.

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.

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.

Speaking of the context of the bug report: On a practical level, there are
two non-Cygwin processes talking via that pipe, even if one of the two
processes is spawned by a Cygwin (or MSYS2) process in the middle. It
might be better if in such scenarios the pipe would be left alone entirely
by Cygwin instead of toggling the blocking/non-blocking mode to begin
with. Such use cases are probably not part of the overall design how pipes
are handled, but maybe they should be.

Ciao,
Johannes

Reply via email to