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

Re: file_handle_cache branch ready for review

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Mon, 9 Jan 2012 07:56:54 -0600

On Mon, Jan 9, 2012 at 2:55 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Stefan Fuhrmann wrote:
>> Ivan Zhakov wrote:
>>>    In your branch your introduce handles to handles.
>>> APR does the same. Is that unreasonable?
>>>  4. It seems current implementation reuses file handles even error is
>>>  occurred when working with the handle. It's potentially dangerous from
>>>  my point view.
>> Interesting point. But I think it will not cause issues in
>> our case because we use it only within a FSFS "session".
>> Any I/O error should result in a failure of the respective FS
>> operation, in turn freeing the whole cache instance.
>> The whole problem with I/O improvement is that there
>> is probably no other way to make progress in the next
>> 3 years: Some of it could be addressed within APR,
>> but that won't be available for Apache < 2.4 (2.6?).
>> A better solution is FSv2 but that is at least 3 years
>> away from now.
> It is worth considering putting this kind of work into the APR source code.  We have close links with APR: some of the APR developers are Subversion developers.  Historically, what we have done before when developing an improvement that is best suited to being in APR, is:
>   * write the new code in Subversion first;
>   * port the new code to APR;
>   * make Subversion use the APR version if it is available, otherwise the Subversion version of the code;
>   * test Subversion using both versions of the code;
>   * submit a patch to the APR project;
>   * wait a few years;
>   * strip out Subversion's own copy of the code.

While I'm all for moving things upstream to APR--I've done it before
myself!--the end result is usually less than optimal.

Realistically, until we allow ourselves to move off of the APR 0.9
series, we still have to haul around our own private implementation of
whatever it is we ported upstream. This leads to all the standard
issues with maintaining two implementations, and usually isn't worth
the effort. Until we can change the minimum required version of APR,
it just isn't worth the hassle.


uberSVN: Apache Subversion Made Easy
Received on 2012-01-09 14:58:19 CET

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