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