D.J. Heap wrote:
> On 4/6/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
>> Finally, one thing that really bugs me about our current scheme is that
>> there's no way to gain access to the common pool at fs open or create
>> time, which means that there's a fair amount of caching-type things that
>> we just can't do.
>>
>> [Recall that the series of calls through the vtable is e.g. "open",
>> "serialised_init(common_pool)", where only the latter is guaranteed to
>> be serialised with other calls (to serialised_init).]
>>
>> I'd much prefer it if we could change the vtable to eliminate the
>> separate serialised_init call, and just serialise the open/create calls
>> (against other open/create calls). (I don't know if there was some
>> reason we didn't do that initially - perhaps I'm missing something?).
>> Is this something that fits with what you're trying to fix as well?
>
>
> The only reason I can think of is some compatibility concern, or maybe
> a performance concen about serializing create/open? I can't see why
> it would be a concern, but I'm not deadly on this code. Maybe Garrett
> or Brane can comment on the pros/cons they see in doing that?
>
> If it's a good idea, then we could eliminate serialized_init, add a
> common_pool parameter (and serialize the calls) to create/open? Does
> it seem reasonable to keep common_pool as a parameter to the init
> functions (and leave the bdb cache init there) as well as add it to
> the create/open?
I really can't recall why we had a separate serialized-init call.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 9 21:33:14 2007