The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Excise process from a pipe
Date: Thu, 10 Jul 2014 12:06:58 -0400 (EDT)	[thread overview]
Message-ID: <20140710160658.DCB1318C09E@mercury.lcs.mit.edu> (raw)

    > From: Larry McVoy <lm at mcvoy.com>

    > Making what you are talking about work is gonna be a mess of buffer
    > management and it's going to be hard to design system calls that would
    > work and still give you reasonable semantics on the pipe. Consider
    > calls that want to know if there is data in the pipe

Oh, I didn't say it would work well, and cleanly! :-) I mean, taking one
element in an existing, operating, chain, and blowing it away, is almost
bound to cause problems.

My previous note was merely to say that the file descriptor/pipe
re-arrangement involved might be easier done with a system call - in fact, now
that I think about it, as someone has already sort of pointed out, without a
system call to merge the two pipes into one, you have to keep the middle
process around, and have it turn into a 'cat'.


Thinking out loud for a moment, though, along the lines you suggest....
Here's one problem - suppose process2 has read some data, but not yet
processed it and output it towards process3, when you go to do the splice.
How would the anything outside the process (be it the OS, or the command
interpreter or whatever is initiating the splice) even detect that, much less
retrieve the data?

Even using a heuristic such as 'wait for process2 to try and read data, at
which point we can assume that it no longer has any internally buffered data,
and it's OK to do the splice' fails, because process2 may have decided it
didn't have a complete semantic unit in hand (e.g. a complete line), and
decided to go back and get the rest of the unit before outputting the
complete, processed semantic unit (i.e. including data it had previously
buffered internally).

And suppose the reads _never_ happen to coincide with the semantic units
being output; i.e. process2 will _always_ have some buffered data inside it,
until the whole chain starts to shut down with EOFs from the first stage?


In short, maybe this problem isn't solvable in the general case. In which
case I guess we're back to your "Every utility that you put in a pipeline
would have to be reworked".

Stages would have to have some way to say 'I am not now holding any buffered
data', and only when that state was true could they be spliced out. Or there
could be some signal defined which means 'go into "not holding any buffered
data" state'. At which point my proposed splice() system call might be some
use... :-)

	Noel



             reply	other threads:[~2014-07-10 16:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 16:06 Noel Chiappa [this message]
2014-07-10 16:04 ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2014-07-18 15:33 Noel Chiappa
2014-07-17 15:42 Noel Chiappa
2014-07-16 21:31 Noel Chiappa
2014-07-14 15:12 Noel Chiappa
2014-07-14 14:13 Doug McIlroy
2014-07-10 16:12 Noel Chiappa
2014-07-10 15:10 Noel Chiappa
2014-07-10 15:11 ` Larry McVoy
2014-07-10  2:49 [TUHS] Subject:unpipeIt'seasy for a process to insert a new process intoapipelineeither upstream or down unpipe Doug McIlroy
2014-07-10  4:52 ` [TUHS] Excise process from a pipe Warren Toomey
2014-07-10  5:00   ` Dave Horsfall
2014-07-10  5:06   ` Christopher Vance
2014-07-10  8:43     ` Warren Toomey
2014-07-10 12:03   ` Doug McIlroy
2014-07-10 12:04   ` Doug McIlroy
2014-07-10 14:45     ` Larry McVoy

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=20140710160658.DCB1318C09E@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).