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

Re: Another 1.4 release critical bug

From: Branko Čibej <brane_at_xbc.nu>
Date: 2006-08-03 15:44:16 CEST

Garrett Rooney wrote:
> On 8/3/06, Branko Čibej <brane@xbc.nu> wrote:
>> Garrett Rooney wrote:
>> > On 8/2/06, Branko Čibej <brane@xbc.nu> wrote:
>> >
>> >> Heh, you just proposed what I proposed. :)
>> >> Basically, for the BDB back-end, we're talking about a significant
>> part
>> >> of the code. Not to mention that doing this would violate the
>> layering.
>> >
>> > Last night another solution occurred to me.
>> >
>> > So, if we need the DSOs to stick around as long as possible, longer
>> > than any pool that could potentially hold an svn_fs_t, then why not
>> > just put them in the global pool? Each pool has a pointer to its
>> > parent, so we just need to climb up that chain until we hit the root.
>> > It's not like we're sticking a huge amount of data in there, it's
>> > bounded by the total number of FS backends, so we should be safe...
>> ISTR that's not thread safe.
> Well, first off, this is in an init function that really really wants
> to be called in single threaded context anyway... So walking that
> chain of parent pools really should be happenning when it's mostly
> safe to do so...
> And honestly, the only way I can see walking that chain not being
> thread safe is if pools above you in the chain are being destroyed at
> the same time (that's the only time their parent pointers can change),
> and sure, that's not safe, but it's also insane...
> Or did you mean actually allocating things out of the global pool
> isn't thread safe? It's just like any other pool, isn't it? There's
> locking all over that stuff...

All I remember is that we used to do something like that, IIRC we set
userdata on the global pool (for iconv contexts?), and had problems
because of it. It was a long time ago, though.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 15:44:50 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.