plugin: sftp transport

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
>>No.  async code cannot call make_synchronous, directly or indirectly.
>>The problem is that make_synchronous doesn't just process the thing you
>>want to make synchronous.  Other deferreds can be handled, leading to
>>concurrency issues.
> 
> 
> Isn't concurrency is the point of using async here?  If you have
> concurrency, to some extent you have to worry about concurrency issues,
> regardless of async vs. threads vs. subprocesses vs. whatever.

No, concurrency isn't the whole point, and it's not always advantageous.
 For Branch.last_revision(), for example, there's not much payoff in
concurrent operation, even for an async program.

One point is to use a bunch of network clients that are already written,
instead of hacking up our own.  Another point is to use the same network
clients, whether we're doing sync or async operations.

>>If there were a way to get the reactor to just process the one deferred
>>we care about, make_synchronous would be safe, and I'd feel a lot better
>>about using twisted.
> 
> 
> This statement doesn't really make much sense to me -- Deferreds and the
> reactor don't inherently have anything to do with each other.

Okay, maybe I'm misunderstanding the specifics.  I thought that the
problem with make_synchronous was that it could not be induced to *only*
process the stream we were trying to synchronously access, and hence
would interact badly with async programs.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDV5Ft0F+nu1YWqI0RAlEXAJ9KE2ihZIiQEY1pl7D2r9vrm+5bAwCfVe+0
WIj0m12w6J90HnNFam/ge5c=
=gLiJ
-----END PGP SIGNATURE-----