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 <[email protected]>
