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 03:11:37PM +1000, Robert Collins wrote:
>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!.

Hmm.  I was referring to the way that Corinna did this originally.  She
used FindFirstFile to get the date.  I'm not sure why she didn't use
GetFileInformationByHandle, or something, but you're right, this
wouldn't be a huge performance hit.

It wouldn't be hard to add this to my patch but I don't think I want to
do this for 1.3.3.  If Corinna wants to augment it or redesign it, though,
I will leave that decision to her.

>> /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 :}.

It's not even a matter of someone changing /etc a lot, actually.  You'd
have to be changing /etc a lot and playing with uids a lot.  I don't
think that there are many programs that do that.  inetd and sshd are
the two that come to mind.

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

These processes aren't going to stop what they are doing every time /etc
changes.  It will only be in the, IMO, rare event that they are playing
with uids or gids that this would be an issue.

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

The passwd and group manipulation are protected by your inclusion of
mutexes.  The cygwin heap isn't shared between processes so there is no
interprocess race possible.  Except, for some iffiness when the heap is
copied during a fork/exec.  There is an inherent problem with one thread
modifying the cygwin heap while a another thread is execing or forking.
It's roughly the same problem as what I recently reported for fork.

I was just mentioning this as something that could be done now.  If we
pass the parent's /etc/passwd information to the child, the odds are
pretty good that the child will never have to read /etc/passwd itself.
However, as I said, when I did this, it didn't seem to have much of an
effect on performance.  Maybe the extra effort of copying the
information from parent to child was enough to drown out any savings.

I'd like to reinvestigate this after 1.3.3, 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.
>
>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? 

I think that Corinna mentioned that we have to have a cygwin that works
without the daemon, actually:

On Tue, Sep 04, 2001 at 11:28:02AM +0200, Corinna Vinschen wrote:
>Ah, and don't forget the the Cygwin code has to stay self-acting.
>If it's impossible to start or to contact a server it should _not_:
>
>- Give up.
>- Hang
>- Dramatically slow down.
>
>All functionality which is still possible should work and all calls
>which actually need the server could return some ENOSYS error code.

While I like the idea of having a server maintain a /etc/passwd database
for cygwin programs to access, I don't think that a program should have
to start the server to find out its uid.

Maybe we just have a separate DLL that will stand in for the daemon
when it is not available for some reason, that would be sufficient.
Even there, I foresee mailing list wails about needing to include
one more thing besides cygwin1.dll with their cygwin programs.

Just to be clear, I'm not against the idea of a server.  This was one of
the ideas that I pitched to Cygnus when I first started working on
Cygwin as my full time job in 1998.  It's one of the few things that I
suggested that haven't been implemented by somebody since then.

cgf


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