Bert Huijben <bert_at_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
Received on 2015-12-07 12:16:41 CET