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, 2001-09-09 at 13:14, Christopher Faylor wrote:
> On Sun, Sep 09, 2001 at 01:02:02PM +1000, Robert Collins wrote:
> >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.

Huh? We _have_ to read the file once. I don't think that extracting the
modification date from an openfile is a likely 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.

True, it can be hard to tell in advance though :}.
 
> 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.

They way I read it, the worst case is the max time a dirty page is
allowed in cache - something like 30 seconds be default. *shrug*.

> >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.

The difference in this I guess is that we are talking about having <n>
cygwin process's _all_ reread the passwd and group data when /etc
changes. If you have 40 or 50 cygwin process's running - say an XFree86
user - this may be rather noticable. If its on the heap there will be
race issues unless it's protected in some fashion, and if we're going to
do that, why have every process try to do the update.

> 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.

I thought that was the point? We _cannot_ get some things done cleanly
and reliably without the daemon. This is why I suggested that the daemon
have an auto-start capability. That is that on 9x and NT if the daemon
is not running, it gets started by cygwin.. of course it won't be in the
System user context, but it should work? 


Rob


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