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

Re: [RFC/PATCH] Handling PROPFIND in mod_dav_svn (was: Re: Issue with browsing a SVN 1.9.2, schema 7, packed, repository)

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Thu, 14 Jan 2016 18:40:11 +0300

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

>> I believe that (1) is much harder than (2).
>>
>> The rewrite of mod_dav pool's usage is a recipe for rarely reproducible
>> crashes caused by lifetime issues. The functions and callbacks often modify
>> or attach allocated data to other objects. We'd also need to deal with
>> per-object subpools like propdb->p, ensure that errors survive up to the
>> proper point of time, provide different API versions compatible in terms of
>> the objects' lifetimes, hope that nobody — API users and mod_dav itself —
>> accidentally relies on something to be allocated in a long-living pool, etc.
>>
>> Frankly, I don't think that this is a realistic approach to the problem.
>>
>
> All the problems you describe are generic problems that apply to *any*
> rewrite of *any* C codebase to change its dynamic memory allocation
> patterns. Your argument could be applied to *any* case where somebody
> proposes to change some library's object lifetime patterns. It implies
> that it is impossible or infeasible to patch a library to have tighter
> lifetime promises.

This doesn't make them less applicable to the scope of what needs to be
done for (1), especially with the specifics of mod_dav's code in mind.

And no, I wasn't implying that it's impossible. What I'm trying to say is
that I don't see it as a viable solution for the particular problem due to it

 - being far more complex than (2)

 - having a higher chance of introducing severe issues that are hard to
   diagnose

 - requiring changes that could affect third-party code (other users of
   mod_dav's public API)

 - having a prerequisite of being very well acquainted with mod_dav's code

 - not solving the problem unless certain preconditions are met (that is,
   either using httpd/mod_dav 2.6.x, once it's released, or being dependent
   on a potentially destabilizing backport to 2.4.x / 2.2.x, or not using
   the officially released version, but a version with the custom patch
   applied)

As opposed to that, (2) is a relatively low-cost solution that also has
certain benefits, allowing us to send less data over the wire or to stop
fetching the same information multiple times from lower levels.

>> And we do have a history of breaking mod_dav (and then reverting changes)
>> with much smaller fixes.
>
> Would you be able to cite concrete examples?

I was referring to

  https://svn.apache.org/r1529559
  https://svn.apache.org/r1531505
  https://svn.apache.org/r1602338

> I think forking mod_dav into mod_dav_svn would be a mistake.
>
> I think you should patch mod_dav.
>
> Can I help with the latter approach? E.g., by reaching out to the
> dev_at_httpd folks, or by coding / testing / reviewing a patch? I will
> have limited time for this since it's not part of my dayjob.
>
> How do we move forward?

Thanks for offering your help.

I started this thread in order to draw attention to the problem and to check
whether what I propose squares with what everyone else is thinking. I am
certainly not going to push (2) forward if people are unhappy with that.

On the other hand, I am confident that I won't be able to pull (1) off, so
I don't plan on doing that. This leaves us with the serious problem that
probably is affecting a lot of users in their ordinary workflow.

Not quite sure on how do we continue from here.

Regards,
Evgeny Kotkov
Received on 2016-01-14 16:40:41 CET

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.