On Mon, 2 Sep 2024 22:50:45 +0900 Takashi Yano wrote: > 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.
Ah... However, if a cygwin app executes non-cygwin app and the non-cygwin app exits, the read pipe remains on blocking mode. Then the cygwin app cannot handle signal on blocking read() after that. Let me consider... -- Takashi Yano <takashi.y...@nifty.ne.jp>
