[PATCH 2 of 3 side-word (+4)] sshpeer: use a 'bufferedinputpipe' for standard output of the ssh process

[Yuya Nishihara]

On Mon, 01 Jun 2015 17:03:01 -0700, Pierre-Yves David wrote:
> On 06/01/2015 04:57 PM, Augie Fackler wrote:
> > On Mon, Jun 01, 2015 at 09:12:31AM -0700, Pierre-Yves David wrote:
> >> On 06/01/2015 08:16 AM, Yuya Nishihara wrote:
> >>> On Mon, 1 Jun 2015 08:01:55 +0900, Yuya Nishihara wrote:
> >>> This will slightly complicate doublepipe, so I'm not sure which is better.
> >>
> >> The original version was doing all in one. However, the buffer version using
> >> the 'os' module is isolated into the 'util' module (we avoid any 'os' usage
> >> in any top module) and the douple pipe which enforce the ssh specific logic
> >> of "forward stderr as 'remote:' output" live in the ssh specific 'sshpeer'
> >> module.

I see.

> >> Do you want me to update the commit message?
> >
> > I think that might help future code archaeologists, so let's go for yes?
> >
> > At this point we've got enough going on I'm having trouble keeping up
> > with all the churn at the protocol-ish layers, so I'm sure in two
> > years we'll be grateful for overly-verbose commit messages.
> 
> Do you want that at documentation for each class as a details in the 
> description for the each commit introducting them ?
> 
> >> (note: at some point we will replace all this with thread).
> >
> > Would we be better off to just code that up now? It might be
> > significantly simpler...
> 
> The current approach just replace on of the core object with something 
> that behave exactly the same but also unsure the server output is 
> consume in real time. This have ø impact on the rest of the code. The 
> object itself is non trivial but the impact on the code is ultra simple. 
> translating all that to threading have a much bigger impact and will be 
> much more complexe. We'll eventually get to there for bundle2 but I 
> would be happy to not be rabbit-holed with a massive refactor for a bug 
> fix that is definitely not on my critical path.

Maybe I'm noob, I don't see the point why we want to move to threading at
some time. (except that we can't do select() on Windows)

doublepipe can wait for both stdout and stderr asynchronously if they are
controlled by single blocking loop, entered by doublepipe.read() or readline()
call. Doesn't bundle2 call these methods in a timely fashion?