[PATCH] Re: pthread -- Corinna?
Tue Apr 17 03:30:00 GMT 2001
----- Original Message -----
From: "Corinna Vinschen" <firstname.lastname@example.org>
To: <email@example.com>; <firstname.lastname@example.org>
Sent: Tuesday, April 17, 2001 8:21 PM
Subject: Re: [PATCH] Re: pthread -- Corinna?
> On Tue, Apr 17, 2001 at 12:51:37AM -0400, Christopher Faylor wrote:
> > On Tue, Apr 17, 2001 at 02:03:19PM +1000, Robert Collins wrote:
> > >I've remembered my key thought:
> > > [...]
> > You probably know this, but, [...]
> > >I think we should [...]
> > Ah right. [...]
> > >> >A true semaphore could [...]
> > >> Still not convinced.
> > >> [...]
> > >Nope, [...]
> > Yes. [...]
> > >Get_id_from_sid should know [...]
> > >> Maybe [...]
> > >Ahh, [...]
> > passwd_state <= initializing
> > >> Hmm, again. [...]
> > >Why don't we [...]
> > I won't disagree [...]
> > Index: security.cc
> > ===================================================================
> > [...]
> Ok, I'm in the subject so I think I should say something here, too.
> You both have told so much, back and forth, that I'm not quite sure
> how to tie in. Anyway.
> Robert is right in that we have two different problems. In my own
> - n>1 threads could try to call read_etc_passwd() nearly
> simultaneously. This is a problem which could be handled by a
> mutex or a critical section handler, perhaps.
> - get_id_from_sid is called from open if and only if ntsec is ON.
> That's a problem which is thread internal. Each single thread
> would have the same problem and it's related to the usage of
> `fopen' in read_etc_passwd() and read_etc_group(). `passwd_sem'
> and `group_sem' are just gatekeeper to avoid the recursion.
> Obviously, the usage of these variables isn't thread safe.
> The joke here is that the kernel (urgh, Cygwin itself) doesn't
> need ntsec. It should always be able to open /etc/passwd and
> So, the better way is probably to drop both ..._sem variables and
> just switch off allow_ntsec in read_etc_...() before opening a
> file and restoring the setting afterwards.
> If that's done inside of the above mentioned mutex or critical
> protected area in read_etc_...(), it's protected against changings
> simultaneous threads, too.
is allow_ntsec thread-specific or process-specific or system specific?
- if it's thread-specific, then that will work.
- If it's process specific, then we need to have every io call that
tests allow_ntsec enter the same mutex (or critical section). That would
be a rather significant performance hit for multithreaded apps. (If they
don't enter the section, then user read & writes will not be tested
against nt_sec during the parsing period.
- If it's system specific then we need a cross-process mutex m and every
io call [...] That would make cygwin _very_ slow for parallel process
I agree that it's the best way, as long as we have allow_ntsec thread
specific. Introducing a cross-thread bottleneck on i/o would be bad idea
More information about the Cygwin-patches