"D.J. Heap" <dj@shadyvale.net> writes:
> Philip Martin wrote:
>>
>>>Is the more explicit cleanup desired in this area because it's dealing
>>>with pipes and files, or was it just the way it was done at the time
>>>or something? Is it ok to create a subpool and use SVN_ERR to bail on
>>>error conditions, or should I explicitly clear it before exiting if
>>>any errors are encountered so that the files/pipes are guaranteed
>>>closed even in the face of errors?
>> Yes, it's the open files that are a particular worry. This function
>> gets called by mod_dav_svn so it could be part of a multi-threaded
>> server process. When that happens there may be multiple commits
>> happening simultaneously in the same process, how many open files are
>> going to exist simultaneously? What sort of limits exist?
>> I suspect that the OS limit will usually be sufficiently high that
>> this is not a problem in practice. It's possible I'm worrying about a
>> problem that doesn't exist.
A bit of further thought on my part. I think we can assume that if
the run_hook_cmd returns an error then the commit is going to be
aborted in the near future, in which case the error handler can be
expected to clear the pool. This means that open files are not really
a problem when an error occurs. What the code must do is ensure that
the non-error path doesn't leave open files, as this when they could
hang around for some time. It should be fairly simple to code explict
file closing for the case when no error occurs, the explict subpool is
not needed.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 6 13:34:00 2003