From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] the sin of buffering [offshoot of excise process from a pipeline]
Date: Wed, 16 Jul 2014 17:46:32 -0400 (EDT) [thread overview]
Message-ID: <20140716214632.6F3DB18C0A2@mercury.lcs.mit.edu> (raw)
> From: Doug McIlroy <doug at cs.dartmouth.edu>
> Process A spawns process B, which reads stdin with buffering. B gets
> all it deserves from stdin and exits. What's left in the buffer,
> intehded for A, is lost.
Ah. Got it.
The problem is not with buffering as a generic approach, the problem is that
you're trying to use a buffering package intended for simple,
straight-forward situations in one which doesn't fall into that category! :-)
Clearly, either B has to i) be able to put back data which was not for it
('ungets' as a system call), or ii) not read the data that's not for it - but
that may be incompatible with the concept of buffering the input (depending
on the syntax, and thus the ability to predict the approaching of the data B
wants, the only way to avoid the need for ungetc() might be to read a byte at
a time).
If B and its upstream (U) are written together, that could be another way to
deal with it: if U knows where B's syntatical boundaries are, it can give it
advance warning, and B could then use a non-trivial buffering package to do
the right thing. E.g. if U emits 'records' with a header giving the record
length X, B could tell its buffering package 'don't read ahead more than X
bytes until I tell you to go ahead with the next record'.
Of course, that's not a general solution; it only works with prepared U's.
Really, the only general, efficient way to deal with that situation that I can
see is to add 'ungets' to the operating system...
Noel
next reply other threads:[~2014-07-16 21:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 21:46 Noel Chiappa [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-07-15 23:43 Doug McIlroy
2014-07-16 0:32 ` Larry McVoy
2014-07-16 3:53 ` John Cowan
2014-07-16 4:05 ` Larry McVoy
2014-07-16 6:03 ` John Cowan
2014-07-16 14:30 ` Larry McVoy
2014-07-16 14:56 ` Dan Cross
2014-07-16 15:41 ` Larry McVoy
2014-07-15 2:31 Doug McIlroy
2014-07-15 2:40 ` Larry McVoy
2014-07-15 18:55 ` scj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140716214632.6F3DB18C0A2@mercury.lcs.mit.edu \
--to=jnc@mercury.lcs.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).