D-Bus core due for a release?

[Havoc Pennington]

Hi,

Tim Dijkstra wrote:
> On Wed, 16 May 2007 14:41:29 -0400
> Havoc Pennington <hp at redhat.com> wrote:
> 
>>> * possibly the user database (it's unclear whether this made it into 1.0.2)  
>> Not sure I remember the current state here, but I thought there was a 
>> patch that needed some performance testing before we put it in.
> 
> Part of it is cleanup; there used to be two copies of the cache, also
> they didn't got expired on dbus reload. The second part is a configure
> switch to disable it altogether, which is the correct thing to do IMHO.
> It will indeed hit performance if you use for example an LDAP server
> _without_ nscd. If you install nscd I couldn't measure a difference. I
> think we shouldn't redesign caching if there is already a caching
> daemom.
> 

Thanks, according to the changelog this patch is in HEAD already (did 
not check 1.0.x). So the issue is just the default for the configure 
switch (or I guess if we change to default to no cache, arguably we 
should just nuke all this code).

I don't think it's only LDAP - it's far too slow with /etc/passwd also I 
think, without nscd.

How does the nscd caching work I wonder - remember on *every* message we 
can do things like get the groups a user is in. So we need that info 
in-process. Does libc keep a client-side/in-process cache also when 
using nscd?

Is there some way to ask libc "is nscd being used"?

We probably discussed all this already and I just don't remember ;-)

Anyway, Simon I would say resolving this is not something to block on 
since there's no regression, though I would still like to resolve this.

Havoc