[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: issue #1573: fs deltification causes delays

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-05 19:09:16 CET

mark benedetto king <mbk@lowlatency.com> writes:

> On Wed, Nov 05, 2003 at 09:52:52AM +0100, Sander Striker wrote:
> >
> > > >> 2. Make svn_fs_merge() spawn a deltification thread (using APR
> > > >> threads) and return success immediately. If the thread fails to
> > > >> deltify, it's not the end of the world: we simply don't get the
> > > >> disk-space savings.
> >
> > For 2. we'd need both a fork()ed and a threaded implementation, based
> > on availability advertised by APR at compile time.
> >
>
> What if we were to do the deltification on the same thread that serviced
> the request, but after the response has been written to the socket?

This was my original idea, but there's an API problem. I don't
believe that Apache guarantees that things we write to our output
stream are flushed to the socket immediately. The *right* way to do
this would be for Apache/mod_dav to provide a post-request cleanup
hook, which is guaranteed to run only after the request response has
been sent down the wire. In that cleanup, we could do the
deltification.

But if Apache doesn't have this functionality already, we don't have
time to wait for another release of that code.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 5 19:10:29 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.