[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2

Dmitry Kurochkin dmitry.kurochkin at gmail.com
Mon Dec 17 22:06:26 UTC 2007


Hi David,

According to cURL changelog pipeline support has been added in version 
7.16.0:

CURLMOPT_PIPELINING added for enabling HTTP pipelined transfers.

I did not use it myself but from the docs it looks like this is just 
what you want. Quote:

CURLMOPT_PIPELINING

Pass a long set to 1 to enable or 0 to disable. Enabling pipelining on a 
multi handle will make it attempt to perform HTTP Pipelining as far as 
possible for transfers using this handle. This means that if you add a 
second request that can use an already existing connection, the second 
request will be "piped" on the same connection rather than being 
executed in parallell. (Added in 7.16.0)

Thanks for your work on darcs (and xmonad :))!

Regards,
  Dmitry

David Roundy wrote:
> On Thu, Dec 13, 2007 at 07:19:02PM -0800, Stefan O'Rear wrote:
>   
>> On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
>>     
>>> Still on my todo list (of issues that you've reported):
>>>
>>> 2. figuring out a nice way to speed up a lazy darcs get.  Currently it
>>>    grabs each file in the repository individually.  This means we're not
>>>    harmed by long history, but we suffer greatly in repositories having
>>>    many small files.  Note that these grabs are cached (if you enable a
>>>    cache) so a second get of the same (or a similar) repository would be
>>>    lightning fast.  But something should be done to (perhaps optionally)
>>>    speed up darcs gets.  Perhaps we could download a tarball of
>>>    _darcs/pristine.hashed with which to seed the cache (or our own
>>>    prisine.hashed).  We could do similarly with the patches directory, in
>>>    fact.  And in neither case would an "old" tarball harm us in any way
>>>    (except requiring that we grab a few more files).
>>>       
>> My (incomplete) understanding is that the majority of the cost consists
>> of round trips (request -> responce, and TCP handshakes) - so just
>> adding HTTP/1.1 pipelining support to Darcs should give almost all of
>> the benefits of a tarball, without requiring a new repository format.
>> (Darcs' non-use of pipelining is also a frequent point of snickering, if
>> you care about such things).
>>     
>
> Any suggestions how to go about doing this? I quick look suggests that
> libcurl can't handle http pipelining, and that no haskell HTTP library does
> so.  The only library I can find that does seem to support it is libwww,
> which looks like a real pain to use.
>
> On top of this is the question of how to execute downloads in parallel.  I
> presume this would require writing some threading code and hints like par
> to spark off parallel downloads.
>
> Is anyone interested in taking this on? It's definitely way beyond the
> scope of what I will have time for.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> darcs-devel mailing list
> darcs-devel at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>   


More information about the darcs-devel mailing list