[PATCH 2 of 3 side-word (+4)] sshpeer: use a 'bufferedinputpipe' for standard output of the ssh process
pierre-yves.david at ens-lyon.org
Mon Jun 1 19:03:01 CDT 2015
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'
>> 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.
More information about the Mercurial-devel