On 11.07.2013 16:31, Michael Pruemm wrote: > I'm trying to learn to use the svn api via the Python swig bindings > for 1.8.0. So I wrote some naive code that calls svn_client_log5 and > in the callback does something like this: > > foreach file in changed_paths: > svn_client_ls3() > > The pool passed to svn_client_ls3 is the one passed to the callback > function. > > (I first tried to use svn_client_list3 but the Python bindings lack > (support for its callback function.) > > This works fine for a while when I access the repository via http:// > but eventually lots of connections are open and the script just hangs > and doesn't even react to ^C. > > When I access the repository via svn+ssh:// it works fine until I > reach a commit that touched more than ~512 files. At that point, svn > is unable to open more connections to the repository, and a process > listing shows that there are 512 active processes connecting with the > repository. > > Apparently, these connections are only closed when the memory pool is > cleared/destroyed but this behaviour is not documented anywhere. Is > this a bug?
No. Pools encapsulate all resource management -- including file handles and sockets (connections), not only allocated memory. This document explains how pools should be used: http://subversion.apache.org/docs/community-guide/conventions.html#apr-pools In your example, you should be using an iteration pool. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com