Hi Samuel, > Which entails adding timeouts on libpipe, contribution welcome!
Right. I had not traced as far as libpipe; the original report framed the fix as a pflocal dispatch-table extension, but if libpipe has no timeout primitive then the real work lives in the lower layer first (libpipe gains a timeout-bearing read path), with the pflocal SO_RCVTIMEO dispatch as the thin wrapper on top. I am not in a position to take the libpipe side of this on a near horizon, so I will not block the slot. If someone else has cycles for it I am happy to be the second reviewer / tester on canonical Debian GNU/Hurd 0.9. For the immediate emacsclient noise the gnu-emacs-side patch is already in review (bug#81160, "[PATCH] emacsclient: suppress ENOPROTOOPT noise from SO_RCVTIMEO on GNU/Hurd"), so the user- visible warning stops at the client even before pflocal grows the option. Thanks, Borja Tarraso [email protected] El dom, 31 may 2026 a las 12:32, Samuel Thibault (<[email protected]>) escribió: > > Hello, > > Borja Tarraso, le sam. 30 mai 2026 22:11:48 +0300, a ecrit: > > This is a request to add SO_RCVTIMEO (and SO_SNDTIMEO by symmetry) to > > pflocal's socket-option dispatch. > > Which entails adding timeouts on libpipe, contribution welcome! > > Samuel
