"Bert Huijben" <b...@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 callback. 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*
