[cc'ing the dev list, please keep replies on it]
Tim Coulter wrote:
> Bliar,
>
>> In my multithreaded Python Ice Subversion server, I have a pool of
>> svn_fs_t's that are checked out and checked back in per RPC request. If
>> the pool is empty, I just create a new svn_fs_t.
>
> I'm trying to get a sense of what you meant by pool. Did you mean an
> actual Subversion pool (whatever class that equates to; something like
> apr_pool_?) or did you simply mean "a set" of them, such as an array
> within the main process?
No, more like a database connection pool, where you borrow a connection for a
while then return it when you are done with it. If the pool is empty, I just
create a new svn_fs_t.
> Also, are your svn_fs_t's linked with the specific paths they associate
> to, so as not to check out the same one twice? For instance, when an RPC
> wants to check out an svn_fs_t for path "/a_path", and the svn_fs_t
> checked out for "/a_path" is in use, will the thread for that RPC wait
> until the "/a_path" svn_fs_t is checked back in? If so, do directories
> work the same way (i.e, will "/some/path" block "/some/other_path"
> because they have the same parent directory)?
No, the svn_fs_t's aren't linked to the path inside the repository.
You can have multiple svn_fs_t's all operate on the same path in the same
repository, so there's no need to block. Just create a new svn_fs_t if you
don't have any available. They don't keep open file descriptors around, so they
are cheap.
My server allows for multiple Subversion repositories, so all RPC calls take a
repository name as one of their arguments, then the name is used to look in the
svn_fs_t pool to see if there is one available for that repository, and return a
new or old one.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 20 01:45:39 2007