[MERGE] Updated sftp_readv

John Arbash Meinel john at arbash-meinel.com
Fri Dec 21 14:14:39 GMT 2007


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

Vincent Ladeuil wrote:
>>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
> 
>     john> Vincent Ladeuil wrote:
>     >>>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
> 
> <snip/>
> 
>     >> But why are you trying to do that ?
>     >> 
>     >> Because your coalesced offsets are so big that you don't want to
>     >> totally buffer them ?
> 
>     john> Yes. But not just that.
> 
> What else ?
> 

Just a quick note, I agree the function can be refactored to make it simpler.
And I think I can do so without creating another class, and still improve clarity.

*I* don't have time to do so right now. But it will go in my stack of things
todo when I get time. I'm still trying to figure out why batching calls to
get_parents_map seems to actually be slower. At least in theory multi-way
bisect should be a lot faster, because it doesn't have to evaluate all the
intermediate nodes each time.

As far as a readv that doesn't read the data, it doesn't work very well with
out-of-order requests. At that point, I would probably recommend inverting it
into a callback model. So you would pass in a handler, and as readv() processes
data, it calls your function with which section it is on, and the data that has
come in.

And we would probably require that callers would accept data in random order.
Then if we wanted, we could write a single adapter that would convert the
out-of-order stream into an ordered stream, since that can be done regardless
of the underlying implementation.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHa8pOJdeBCYSNAAMRAsH1AKCNx9zT/nBjBNiG3z1bMK5R+zVfcACgi66i
unIBq3eEmZkC6GTYl2dRn4U=
=RZsh
-----END PGP SIGNATURE-----



More information about the bazaar mailing list