-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 7/18/2009 7:50 AM: > Hi Akim, > >> We, at Bison Corp., have some bug occurring on Tru64 >> (http://lists.gnu.org/archive/html/bug-bison/2009-06/msg00004.html >> ) that seems to be related with our piping into GNU M4. Bison >> basically reads its input, feeds m4 with various files, and "parses" >> the output of m4 before producing the expected files. > > Such piping, where you write from the current process and read into > the current process, may hang on BSD systems, because some data is > present in system buffers but the system wants the buffers to be full > before it continues. A fix for this hang is to enable non-blocking I/O > and use a loop with select() that alternately reads and writes. See > <http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/src/msgfilter.c;hb=HEAD#l580>
Any chance of porting that over to gnulib? At any rate, my understanding is that bison's use of a subpipe is to call m4, which, thanks to the way diversions are used, produces no output until after all the input has been consumed. Thus, bison's usage pattern is immune to this particular deadlock. But you are correct that to avoid deadlock in a generic filter child application, portable applications cannot write more than PIPE_MAX bytes without checking whether the read end needs draining, and the application must be careful enable non-blocking I/O to avoid problems with partial buffers. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkph1z4ACgkQ84KuGfSFAYD74wCgvqmHdp+3F9L8IWVxYpAEg5tG m8AAoIX2lsfM18+16XcYPM5uerd5elaC =jBL6 -----END PGP SIGNATURE-----
