Hi Takashi, On Mar 31 20:59, Takashi Yano wrote: > Hi Corinna, > > I have considered for a several days for: > https://github.com/msys2/msys2-runtime/issues/270 > but, the situation is not well. > > There are two problems if the pipe size is zero. > > (1) select() does not work for that pipe because PeekNamedPipe() > always returns 0. Read side is ready to read only when the > write side is about to write but there is no way to know that. > (2) The cause of the problem: > https://cygwin.com/pipermail/cygwin/2025-January/257143.html > cannot be avoidable. To avoid CancelIo() problem, the patch > https://cygwin.com/pipermail/cygwin-patches/2025q1/013451.html > restrict to write only data less than the current pipe space. > However, if pipe size is zero this is impossible. > > If we think only about bison calld from native ninja, > https://github.com/msys2/msys2-runtime/issues/270#issuecomment-2758310515 > can be a solution, but if the cygwin app called from native ninja > uses select() or interruption while write(), it will not work > properly. > > Any idea?
The ninja maintainers should be nudged so that they change the pipesize. I'm sure they will be willing, if they know what happens when pipesize is set to 0. Apart from that, the only workaround I can see for the Cygwin to naive ninja problem is to tweak pipe_data_available to return PIPE_BUF if fpli.WriteQuotaAvailable == 0 && fpli.InboundQuota == 0. Right now it would return fpli.InboundQuota, i.e. 0. I don't think we can do more than that. Corinna
