"Sander Striker" <striker@apache.org> writes:
> >> I really, really don't get this. Are you saying that
> >> rep_write_close_contents() is being called multiple times on retry?!
> >
> > Yes, it's all part of a very large trail.
>
> Sorry for being so ignorant, but without an explanation of how this
> works (the trail and the reason for calling rep_write_close_contents twice)
> it comes across as broken :(.
>
> Can you please elaborate so I can feel warm and fuzzy about the fs code
> again? ;) :)
Notice that svn_fs__rep_contents_write_stream() doesn't actually
*call* rep_write_close_contents(). It just sets it as the close
function on a stream. Now, that stream might ultimately outlive the
particular public fs function call that created it. For example:
svn_fs_apply_textdelta
CALLS svn_fs__retry_txn(txn_body_apply_textdelta)
CALLS svn_fs__rep_contents_write_stream
CALLS svn_fs__dag_get_edit_stream
When this is all done, svn_fs_apply_textdelta() has returned a window
consumer that expects that stream to still be available for writes!
This is why, in svn_fs__rep_contents_write_stream(), the write baton
is not allocated in trail->pool, but in an explicitly passed pool.
So the stream must be useable outside the particular trail in which it
was created, that is, the trail in svn_fs__retry_txn() in the call
stack above. That's why rep_write_close_contents() and
rep_read_contents() are special, in that they can create their own
trail internally (though that isn't directly relevant to your
question, it's just an interesting side note. And the reason they
have the option to use the passed-in trail is that that's what you
always want to do when possible, to avoid deadlock).
Anyway, when that stream is finally closed, years later, there's no
way for us to know how many retries (that is, the retry loop inside
svn_fs__retry_txn) it will take. Like any other function that happens
inside a trail, rep_write_close_contents() must be be reinvokable --
not necessarily reentrant, just redoable, since there's no telling how
many times the whole trail might get run before it succeeds.
We were violating the retryability rule, since an md5 context can only
stand to be finalized once.
Does this help?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 28 21:36:08 2003