Hi Takashi, I think you should push your original patch to the 3.5 branch for now, and we test the big change in the main branch first.
Thanks, Corinna On Sep 5 22:18, Takashi Yano wrote: > 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>
