Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sat, 8 Sep 2001 23:14:27 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: [RFA] A kinder, gentler check for /etc/{passwd,group} changes Message-ID: <20010908231427.A17466@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20010908225133 DOT A17336 AT redhat DOT com> <1000004523 DOT 13692 DOT 20 DOT camel AT lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1000004523.13692.20.camel@lifelesswks> User-Agent: Mutt/1.3.21i On Sun, Sep 09, 2001 at 01:02:02PM +1000, Robert Collins wrote: >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 :]. I really don't think that the extra bookkeeping required to do this will be worth it. It would mean adding Corinna's original checks back into the mix. So, we'd be saving the file modification time at the beginning, which is a performance hit. /etc is supposed to be a relatively static area. I think it is pretty unlikely that we'd be seeing noticeable performance hits unless people are making continual changes to that area. I don't think that this is actually something that would lend well to benchmarking. I'd say let's try it and see what happens but we really need real-world test cases for this. There is the issue of exactly when the changes will be noticed. MSDN mentions that the change notification might not occur until the data is actually physically on the disk rather than at the instant that it is written. I don't know if that will be a problem or not. >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. We could put the passwd data in the cygheap right now. That would eliminate the need for execed processes to reread it. The data is already stored in the heap, so forked processes already get to see it. I did something like this a while ago but didn't see much of a performance gain, though. This is one of the things about the daemon that trouble me. If we put this kind of functionality in the daemon then cygwin will have to rely on it. It won't be functional without it. Either that or we'll have to keep the old code around -- which will lead to code bloat. Also, I think it is pretty unlikely that the daemon will be around in time for 1.3.4. I guess I could be pleasantly surprised, though. cgf