This is the mail archive of the cygwin-developers@cygwin.com 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]

Re: [RFA] A kinder, gentler check for /etc/{passwd,group} changes


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


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