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

Yuya Nishihara yuya at tcha.org
Wed Jun 3 07:37:37 CDT 2015

On Tue, 02 Jun 2015 11:38:08 -0700, Pierre-Yves David wrote:
> On 06/02/2015 07:11 AM, Yuya Nishihara wrote:
> > 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:
> >>>> (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)
> Moving to threading would allow use to stream a bundle out, while
> receiving a bundle in. (or even non bundle thing) allowing more powerful
> and faster interaction.
> It would also requires less hack with pipe and buffer.

Well, but it would require another sort of hack to process SIGINT while
sub thread is blocked by I/O wait.

More information about the Mercurial-devel mailing list