Re: svn_delta_path_driver(), its purpose and future

On Tue, Nov 29, 2011 at 4:20 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 11/29/2011 04:56 PM, Hyrum K Wright wrote:
>> I understand and expect that consumers of SDPD as currently
>> implemented will need to use Ev1.  The problem is that they don't take
>> very kindly to instances where Ev1 is driven in an asynchronous mode,
>> which doesn't technically violate the Ev1 API.  But I think this is a
>> problem that we can work around.
>
> But ... but ... the code sites which are using SDPD *are* the drivers of the
> editor, not the implementors.
>
> Maybe you meant, "they don't take very kindly to instances where Ev1 doesn't
> immediately return an error because all the real work is done by a nested
> Ev2 in a big batch at the end of the Ev1 drive" ?

Let me offer a concrete example, in the hopes that I can make some
sense. I use the term "sender" to mean "the thing that is invoking
the editor callbacks" and "receiver" to mean "the thing who is
providing callbacks to be invoked". I believe these are the
traditional uses of the terms; if not, I've got some more reeducation
to go through.

In libsvn_client/mergeinfo.c there is a function named
svn_client__elide_mergeinfo_catalog() (or SCEMC for short). SCEMC
uses SDPD to elider mergeinfo and uses a default Ev1 editor with only
custom open_root() and open_directory() handlers[1]. It provides this
editor to SDPD.

Without the shims, everything works well, but when the delayed-run
action of the shims is inserted, we get crashes. The reason for this
is that with the shims, the SDPD callback is invoked prior to any
open_directory() handlers of the editor are invoked, and the SDPD
callback depends upon state which the open_directory() handler sets.

Basically, the delayed processing of the Ev1 open_directory() handler
is combined with the *immediate* handling of the SDPD callback, which
results in out-of-order execution of the SDPD callback, and from there
badness ensues. My thought is to move the shim insertion inside SDPD
and make it clever enough to delay calling the SDPD callback until the
Ev1 queue is played back, thus ensuring the ordering is then correct.

-Hyrum

[1] In this case at least, the code site where SDPD is used *is* the
implementor of the editor, not the driver. SCEMC provides an editor
to SDPD which it then drives.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/