This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Testers needed: New passwd/group handling in Cygwin


On Feb 25 21:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The stuff in the `id' application is not cached at all.  Caching is
> > inherited from the parent process, but the parent never asked for all
> > your groups so it hasn't cached this information.  Every invocation of
> > id has to request the group info anew.
> 
> OK, then I was misunderstanding what caching meant.  I was operating
> under the assumption that there'd be something like a session cache that
> serves all Cygwin processes in the same process tree.

Right now the cache is in the cygheap, so it's per-process, with
inheritance from the parent process.  I am mulling over adding other
caching methods, but I'm reluctant to add another shared memory region
of variable and potentially big size to the 32 bit version of Cygwin.
I'm not as reluctant to do this for the 64 bit version, but I *am*
reluctant to add different code for 32 and 64 bit.

> > Do you have a very slow connection to your DC by any chance?  I admit
> > that I never tested with 440 groups, only with about 30 or so, but 13
> > seconds sounds *very* lame.
> 
> That's around 33 lookups per second; not great, but also not bad (I'm
> far from the only user of that DC obviously).  I'll have to check what
> our web application server is doing (albeit it uses a connection pool to

Sorry, I don't grok this.  What has a web application server to do with
asking a DC for user info?

> than about 200 peak.  The answers can be insanely large depending on
> what and how you ask, too.  In any case, based on the fact that I'm
> certainly not in as many groups as some other folks, I don't think I can
> drop file-based operation at the moment (which I really hoped I could).

Erm... how often are you calling id, usually?  Also, we're in the early
stages of testing this change.  The idea is not that you just switch,
the idea is that we *test* this and I get enough feedback to be able to
ease the biggest pains.

Other than that, I just had an in-shower inspiration how to speed up
`id' specificially.  The getgroups(2) call is in the center of this and
I could probably speed up the stuiff a lot by opening the LDAP
connection in getgroups only once. 

Also, more radically, if we drop the functionality to define another
group name for a group, we could drop the requirement to open an LDAP
connection to fetch group information to the DC entirely(*).  This would
only affect domain groups, local groups could still have different
names.  But I'm already wondering for a couple of days if having a
Cygwin group name different from the Windows group name is really
necessary at all.  I added this years ago for fun, but there's no
serious reason I can think of which would require to keep up with this.

(*) Assuming the group info is cached in the local LSA, which is
    pretty likely for the groups of the current user.

> > The fact that the shells are doing it right seems to indicate that this
> > isn't a generic problem.  I can't debug this, though.  Can you see if
> > you can figure out what's going on under the hood?  Does strace show
> > anything of interest?  Can we perhaps set up some joint debugging via
> > private mail during the next couple of days?
> 
> I can't dig further into this for the next two weeks.  I need to get
> some work done, so I have rolled the snapshot back for now.  I'll get
> back to you when this is out of the way, thanks for the offer.

Sigh.  Testing in this tempo will take ages.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpLIlARYjjgu.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]