Re: fds beyond 0/1/2

[Nicolas Williams <Nicolas.Williams%oracle.com@localhost>]

On Wed, Aug 25, 2010 at 06:13:44PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, August 25, 2010 04:48:31 PM -0500 Nicolas Williams
> <Nicolas.Williams%oracle.com@localhost> wrote:
> 
> >That's true in the pty case (because the stdout/stderr distinction is
> >lost before the writes even happen as the two fildes will both refer to
> >the same pty).
> >
> >It's not necessarily true in the no-pty case.  If the server uses two
> >distinct pipes for stdout and stderr then the relative ordering of
> >stdout/stderr writes will be lost.
> 
> But it's _already_ been lost, because there is no guarantee that the
> server will see those pipes become readable in the order in which
> the app wrote to them; they may even become readable at the same
> time.  [...]

There was never any way to preserve the interleave order of
stdout/stderr writes because if they are the same pipe/whatever then the
order is lost immediately, and if they are not then the order is lost...
immediately.

But I agreed already (maybe the "That's true in the pty case / not
necessarily true in the no-pty case" bit was confusing).  I think we're
just in agreement :)

> The only way to preserve relative ordering of stdout/stderr for the
> server to send them in the right order is for the server and app to
> have a communication channel that is already interleaved, either
> through something more complex than a pair of pipes or because
> they've already been combined into a single stream, as in the pty
> case.

No such thing exists in Unix/POSIX systems.

Attempting to preserve stdout/stderr relative ordering was always a
mistake.  But I don't know that that was ever the goal.  My guess is the
goal was to allow I/O redirection for stdout/stderr separately on the
client side, and the "extended" data thing was just a hack.  Using a
separate "linked" channel would have prompted one to wonder why have
bidirectional channels at all, which might have opened a can of worms.

OTOH, thinking about this now, I suspect linked one-directional channels
could actually simplify the implementations.

> >Do you really need the multiple fd thing?
> 
> It seems like it would be useful.  I've certainly encountered
> situations where it was useful to connect multiple fds between
> processes running on the same machine, and what is ssh if not a way
> to start and communicate with processes running on some other
> machine?

Complex shell scripting scenarios come to mind, yes.

> >Sounds like you might need to
> >do some violence to the connection protocol...  Well, maybe not so much
> >violence, just a way to link channels.
> 
> I don't think it'd be too bad.  I can think of three ways to do this:

Sure.