[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] trivial put test case fails?

From: Christian Vest Hansen
Subject: Re: [Fab-user] trivial put test case fails?
Date: Mon, 23 Feb 2009 00:57:13 +0100

On Sun, Feb 22, 2009 at 2:18 PM, Jeff Forcier <address@hidden> wrote:
> On Sun, Feb 22, 2009 at 5:23 AM, Niklas Lindström <address@hidden> wrote:
>> And it worked. It hasn't stalled during my runs. (And seems like a
>> logical order of things.)
> That's pretty crazy; I was the one who updated that functionality last
> and I'm pretty sure I had it all working 100%. Certainly I had to try
> many different tactics -- including moving around the join() and
> recv_exit_status() calls -- before I got consistently good behavior
> out of the darn things :) Here's hoping that tweak doesn't cause other
> issues for you!

Maybe you just got consistently lucky timing :)

I'm not blaming you though. Reasoning about concurrency can be pretty
hard, and Python does _not_ help and neither does the paramiko

>> * Changing `chan.recv(65535)` changed nothing (tried both this alone,
>> and along with recv_stderr).
> This wouldn't have made a positive difference for the most part; the
> point of that line is to try and grab as much as we possibly can out
> of the channel; lowering it should only have led to the loop running
> more times,

Having the loop run more times was exactly what the experiment was
about. There's a lot of locking and blocking going on inside paramiko,
and I wanted to know if exercising these locks more often had a
side-effect on our issue at hand. If such a side-effect had been
observable, it might have hinted toward a problem inside paramiko

> and a slightly higher chance of losing the tail end of
> some of the output (in the case where we get the "no more data" signal
> from the channel before we've actually recv'd the entire thing).

I think my latest changes should have reduced this chance to zero.

> Both of these are irritating and hard-to-get-right quirks of this kind
> of approach, which as I've been saying is why I want to try Twisted.

Indeed. Inversion of control is an excellent fit for a lot of
multi-threaded code.

> We'll see =)
> Best,
> Jeff

Venlig hilsen / Kind regards,
Christian Vest Hansen.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]