[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with create_pipe_bidi

From: Eric Blake
Subject: Re: Help with create_pipe_bidi
Date: Sat, 18 Jul 2009 08:07:58 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/

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
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]