Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin-developers AT sources DOT redhat DOT com
Subject:	Re: [RFA] A kinder, gentler check for /etc/{passwd,group} changes
From:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To:	cygwin-developers AT cygwin DOT com
In-Reply-To:	<20010908225133.A17336@redhat.com>
References:	<20010908225133 DOT A17336 AT redhat DOT com>
X-Mailer:	Evolution/0.13 (Preview Release)
Date:	09 Sep 2001 13:02:02 +1000
Message-Id:	<1000004523.13692.20.camel@lifelesswks>
Mime-Version:	1.0
X-OriginalArrivalTime:	09 Sep 2001 02:48:54.0275 (UTC) FILETIME=[F6CCA530:01C138D9]

On Sun, 2001-09-09 at 12:51, Christopher Faylor wrote:
> Here's what I did, based on the FindFirstFileChangeNotification ideas.
> 
> It seems to get performance back down to around 1.3.2 levels when
> combined with a couple of other minor changes.
> 
> Now that I see the patch, I realize that the etc_changed function
> probably belongs in miscfuncs.cc rather than in dcrt0.cc.
> 
> The only thing I don't know is if the etc_changed function actually
> does anything useful.  I don't have a useful test case for that but
> I thought that Corinna might.
> 
> Btw, I really like the way that Corinna handled the passwd_state stuff.
> It was, IMO, an elegant use of C++.
> 
> I wonder if we could generalize the similar code in passwd.cc and grp.cc
> into some kind of class for 1.3.4...

I though even numbers where GnuPro only? 

> cgf
> 

I still maintain that we should check the specific file alteration date
before blindly re-reading it. For large password or group files that
will save a little bit of time. And that becomes relevant if /etc is
changing a lot for some reason :].

The other thing that is worth considering (1.3.4/5 again) IMO is putting
the parsed user and group data into a mutex protected mmapped area and
having the daemon handle updating it. That way there will be even less
overhead than there is today.

Rob

- Raw text -