Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Dec 2001 23:13:28 +0000
From:      chkno@dork.com
To:        freebsd-questions@freebsd.org
Subject:   sh redirect caching issue with fifos
Message-ID:  <20011218231234.SAAW19716.rwcrmhc51.attbi.com@chk.phattydomain.com>

next in thread | raw e-mail | index | archive | help
English:
        A function named "fout" which will read from stdin, break
        up input by lines, and output each line one at a time to
        the given named pipe (fifo).

sh:
        fout () { while read a;do echo $a > $1;done; }


The idea being that you could, for example:

$ mkfifo blarg
$ cat /usr/share/dict/words | fout blarg

(then, elsewhere)

$ cat blarg
A
$ cat blarg
a
$ cat blarg
aa
$ cat blarg
aal
$ cat blarg
aalii

etc., getting one word at a time.

However, if you go & try this, it doesn't operate as outlined above.
For each access of the fifo, it returns anywhere from 1 to ~5000
words.  sh caches the lines redirected with ">", and then writes
them in chunks.  This is a great optimization for flat files, but
it goes aginst the intention of the code when used with fifos.

Changing the function to:

        fout () { while read a;do echo $a > $1;sleep .001;done; }

fixes this issue, and makes the fifo accesses return one line at a
time, but only if sh gets a chance to run often enough.  If the load
average goes above 10 or so, multiple lines per read will start to
slip through.  Bumping the sleep value all the way up to .1 buys
you some more reliability, but breakes down (on my system) at about
a load average of 30.  Bumping the value higher makes the code
unacceptably slow, and is still prone to breakage if the LA rises
high enough.


Options, ideas, other workarounds?  Am I doing something stupid?

--
chkno
chkno@dork.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011218231234.SAAW19716.rwcrmhc51.attbi.com>