Re: Help with create_pipe_bidi

[Eric Blake]

-----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             address@hidden
-----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-----