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