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...
-garrett
Received on Thu Aug 3 15:42:19 2006