Bert Huijben <b...@qqmail.nl> writes: > What is the real problem you try to solve here? > > Ra apis are not able to support other apis during callbacks or when editors > are open… This is part of the ra contract as documented in svn_ra.h. > > I don’t think we explicitly want to support users who break this contract.
[...] > Ra local supports a lot of things because it is a very thin layer over the > lower layers… (I once accidentally found out that you can get very far > passing bad batons during commit). But the only thing we promise is that it > supports the ra contract. This change is not about providing support for cases when someone violates the RA contract: * The caller may not perform any RA operations using @a session before * finishing the report, and may not perform any RA operations using * @a session from within the editing operations of @a update_editor. That's because the situation is different when zero-copy code path is being used. In that case, the caller can't use the FS API or any other API functions using FS API from the callbacks, even if they occur on a completely unrelated object. This is so because the zero-copy send happens while holding the lock for the cache. The cache object is a per-process singleton, so, the callback is executed while basically holding a global mutex. We are lucky that, for instance, svnsync doesn't use the reporter in its implementation, but an arbitrary svnsync-like application or other API users have a chance of hitting the described problems once they perform an API call from within the editor callback. As another example, our diff editor can perform RA calls using an extra RA session in some cases. If a call like that happened from within a zero-copy code path, it would cause problems in the ra_local case. Regards, Evgeny Kotkov
