Daniel Shahaf <[email protected]> writes: > Where should we introduce dual pools?
Every function that returns a result allocated in a pool is a candidate. I think it requires more justification for such a function to be single pool. > The callstack is single-pool all > the way to the public entry point svn_version_extended(). Maybe svn_version_extended() should have been dual pool from the start. > We prefer to > avoid creating subpools in functions that don't do a lot of work, so if > we want to convert to dual-pools we'll need to revv that function. svn_version_extended() runs subprocesses and reads files, in syscall terms that might count as "a lot of work" so perhaps a subpool is justified. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
