On Fri, 27 Jun 2025 12:25:18 +0200 (CEST) Johannes Schindelin wrote: > Hi Takashi, > Good explanation, thank you for improving your commit message writing > skill.
Thanks. > > Also, pipe_data_available() returns PDA_UNKNOWN rather than 1 when the > > pipe space estimation fails so that select() and raw_write() can perform > > appropriate fallback handling. > > This looks unrelated? Would this not rather be in a separate patch, to > make it substantially easier to review for correctness? I'll make a separate patch. > P.S.: One thing that strikes me as immediately concerning is this part: > > > - if (avail < 1) /* error or pipe closed */ > > + if (avail == PDA_UNKNOWN && real_non_blocking_mode) > > + avail = len1; > > That means that the next loop iteration will call `NtWriteFile()` with > `len1` bytes (`len1` now being identical to `avail`), even if `len1` can > be substantially larger than `PIPE_BUF` (in my tests, it got stuck at > `len1 == 2097152` in some instances), which is highly likely to be > undesirable. I don't think so. avail = len1 is performed only when real_non_blocking_mode. In real non blocking mode, we can call NtWriteFile() with larger data than actual pipe space without blocking. When you observed `len1 == 2097152`, perhaps avail was 1, I guess. -- Takashi Yano <takashi.y...@nifty.ne.jp>
