Daniel Shahaf <d...@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@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
