The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] Excise process from a pipe
Date: Thu, 10 Jul 2014 08:11:11 -0700	[thread overview]
Message-ID: <20140710151111.GE24876@mcvoy.com> (raw)
In-Reply-To: <20140710151021.3ABE018C09F@mercury.lcs.mit.edu>

In BitKeeper we've got lots of code that deals with jiggering where
stdout goes.  Making that work on all the Unix variants and Windows has
been, um, challenging.  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 followed
by a reconnect.

If you really think that this could be done I'd suggest trying to write
the man page for the call.  I'm not trying to be snarky, in my personal
experience I've found the best way to prove out my own ideas is to try
and document them for other programmers.  If the docs feel like they
make sense then the idea usually has merit.  I don't know how I'd write
the docs for this stuff and have it work with the existing semantics.

On Thu, Jul 10, 2014 at 11:10:21AM -0400, Noel Chiappa wrote:
>     > From: Larry McVoy <lm at mcvoy.com>
> 
>     > Every utility that you put in a pipeline would have to be reworked to
>     > pass file descriptors around
> 
> Unless the whole operation is supported in the OS directly:
> 
> 	if ((pipe1 = process1->stdout) == process2->stdin) &&
> 	   ((pipe2 = process2->stdout) == process3->stdin) {
> 		prepend_buffer_contents(pipe1, pipe2);
> 		process1->stdout = process2->stdout;
> 		kill_pipe(pipe1);
> 		}
> 
> to be invoked from the chain's parent (e.g. shell).
> 
> (The code would probably want to do something with process2's stdin and
> stdout, like close them; I wouldn't have the call kill process2 directly, that
> could be left to the parent, except in the rare

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 



  reply	other threads:[~2014-07-10 15:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 15:10 Noel Chiappa
2014-07-10 15:11 ` Larry McVoy [this message]
  -- 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 16:06 Noel Chiappa
2014-07-10 16:04 ` 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=20140710151111.GE24876@mcvoy.com \
    --to=lm@mcvoy.com \
    /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).