Hi Corinna, Ken and Johannes On Mon, 2 Sep 2024 23:33:13 +0900 Takashi Yano wrote: > 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...
I have submit a new patch for these issues. With this pathch the strategy of pipe read/write for blocking/non-blocking is re-designed. To eliminate toggling the pipe blocking mode, cygwin pipe is always blocking mode basically, and non-blocking mode is sumulated by raw_read() and raw_write(). The new patch will be posted shortly with subject: [PATCH] Cygwin: pipe: Switch pipe mode to blocking mode by defaut What do you think of this idea? -- Takashi Yano <takashi.y...@nifty.ne.jp>
