[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1548823 - in /subversion/trunk/subversion/libsvn_fs_x: dag.c id.c id.h temp_serializer.c temp_serializer.h

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 07 Dec 2013 13:15:44 +0100

On 07.12.2013 11:00, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
>> Sent: zaterdag 7 december 2013 10:31
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1548823 - in
>> /subversion/trunk/subversion/libsvn_fs_x: dag.c id.c id.h temp_serializer.c
>> temp_serializer.h
>>
>> Author: stefan2
>> Date: Sat Dec 7 09:30:42 2013
>> New Revision: 1548823
>>
>> URL: http://svn.apache.org/r1548823
>> Log:
>> Add a pool member to the internal representation of FSX IDs and
>> thus allow the ID vtable functions to perform actual data lookups
>> in the future. The pool is the one used to allocate the ID.
> With WC-NG we explicitly stopped adding a pool in this kind of structures for very good reasons. All these pool reference makes it harder and harder to properly allocate results. This pattern is far too sensitive to pool cleanup ordering problems
>
> Using proper result and scratch pool (where the scratch pool is always the result pool or a descendant of the result pool or at least a pool that is cleaned up *before* the result pool), makes pool cleanup handling much easier to understand...

Couldn't agree more. Structs carrying their own pools around (except in
very limited cases, such as stringbufs and similar) are dangerous.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-12-07 13:16:27 CET

This is an archived mail posted to the Subversion Dev mailing list.