On Wed, Jun 6, 2012 at 2:00 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
>...
> It does indicate a problem with the API. The svn_wc__db_t that is
> contained in the wc/client context object holds on to wcroots and wc.db
> file descriptors after the working copy operations complete. The file
> descriptors in particular are a limited resource.
>
> It's not clear how a long-lived application is supposed to manage these
> wcroots/descriptors. Should the application be recycling context
> objects regularly? Should it use a context object per working copy? Or
> a context per high-level operation like update/commit?
>
> Perhaps holding onto the wcroots/descriptors is a mistake. Should
> Subversion be closing wcroots/descriptors before returning from each
> high-level operation?
Well... semantically, we're just talking about a cache here. The only
issue is that we don't have normal cache controls over it.
I was thinking about this while running errands, and would propose an
API like this:
void svn_client_decache(cctx, bool release_memory);
The function would release all file handles, and (optionally) reduce
its memory footprint, too. With regards to wc_db, keeping the
directory/wcroot information is very handle and avoids a lot of disk
activity. But we could release the memory, too. (and definitely close
all SDB objects)
Applications can decide when/where to call the above function.
I would also propose a new flag in the cctx, name auto_decache which
defaults to FALSE. Applications can choose to turn that on, and we
will attempt to decache before returning from any client operation.
(but I'm gonna bet that it will be "leaky" and we won't always get a
chance to decache due to errors or missed return modes)
Alternatively, we just skip all this and inform long-lived clients
about our caching behavior, and expect them to periodically recreate
the cctx. (and I'll note that for 1.7, they're already aware of this
caching behavior; dunno how they've dealt with it)
Cheers,
-g
Received on 2012-06-06 21:15:21 CEST