Quoting Daniel Rall <dlr@finemaltcoding.com>:
>
> On Aug 26, 2007, at 1:05 AM, Lieven Govaerts wrote:
..
> > In mergeinfo-sqlite-index.c/svn_fs_mergeinfo__get_mergeinfo(), but
> > also
> > in svn_fs_mergeinfo__update_index and
> > svn_fs_mergeinfo__get_mergeinfo_for_tree the call to sqlite3_close is
> > not in the 'finally' path (in java terms), so whenever there's an
> > error
> > accessing the database it's not closed correctly.
> >
> > Does this make sense?
>
> Thanks for the report, Lieven. I've added some simple error handling
> improvements in r26340 which fix this problem.
That should do it. One small remark: What do you think of renaming the
MAYBE_CLEANUP macro to CLEANUP_ON_ERROR, extending it
to take the 'err' variable as parameter and move to a
common include file so we can use it throughout whole the code? I've found
hundreds of instances where we use this pattern, might as well make it more
standard.
> I was wondering, though -- should we also attach the same sort of
> connection cleanup code to a pool cleanup function? Or would that be
> needless additional complexity?
As far as I see in the code we open & close the db connection in the scope of
one function, there's no handover of ownership involved. I don't think there's
much value to registering a cleanup function right now, if we're sure we handle
all return paths correctly.
Lieven
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 28 13:36:22 2007