"Bert Huijben" <bert_at_qqmail.nl> writes:
> Perhaps it would be easier for all callers if the (inner) handler that
> allocates the hash table installs a cleanup handler on it that releases all
> the svn_error_t instances on pool cleanup of the release pool?
> Now all callers that have access to the results have to cover for the
> hopefully unlikely case where there are both global and per node errors,
> while such a cleanup handler would allow all of them to use the standard
> error pattern.
> (The code iterating the hash would also have to cover for errors further in
> the hash table, etc.)
I've been considering going back to a callback API, like the RA
function. I did start off with a callback API but as I don't want to
invoke the callback until the FS layer has released the repository
write-lock so the FS layer has to build up some sort of hash/array of
results. I decided to return the hash an let the caller decide how to
handle it, but we could iterate over that hash/array and invoke a
With a callback API the repos layer would intercept the FS callback and
use it to build a list of paths for the post- hook. Then the question
is can the repos layer invoke it's own callback before running the post-
hook or does it have to build up a hash/array and iterate after the
post- hook? Perhaps it does make sense to invoke the repos callback
before running the post- hook. The result of the post- hook is the
return value of the repos function.
A callback API would mean that the error handling is less prone to
leak. The FS layer would be responsible for clearing the per-path
errors after invoking the callback. The repos layer would simply pass
the error through to its own callback. The callers callback handler
would be able to inspect the error but would not clear it.
One question is what happens when the callback returns an error. I
suppose that stops further callbacks being invoked and eventually the
function returns the callback error back to the caller. Does it stop
the post- hook being invoked?
I've also been thinking about Julian's suggestion of some sort of hash
constructor to make locking/unlocking a single path easier. I think its
probably the wrong thing to do since the existing svn_fs_lock and
svn_fs_unlock are much better wrappers. I think the real questions are
whether svn_fs_lock should remain not deprecated and if so whether
svn_fs_lock2 should become svn_fs_lock_many.
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-03-29 11:38:30 CET