This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set


On Sep 14 22:09, John Carey wrote:
> On Sep 14 09:11, Corinna Vinschen wrote:
> > I applied the below patch to Cygwin CVS and it appears to work nicely.
> > The only potential race I can think of is, if another thread of the same
> > Cygwin process calls SetCurrentDirectory.  I'm inclined to let this
> > situation slip through the cracks since SetCurrentDirectory will already
> > mess up a mixed-mode Cygwin process.
> >
> > The "wincap.has_transactions ()" is just for testing.  If we can use
> > that code, I would replace is with something like
> > "wincap.has_messed_up_cwd_handling()" or so.
> ...
> 
> I would argue against introducing a race with threads that call
> SetCurrentDirectory(), for at least the following reasons:
> 
> 1. The race can be avoided without too much grief.

Right.  Still, the licensing issue...

> 2. If a program does violate the rule against calling
> SetCurrentDirectory() directly (possibly because of
> some third party DLL being involved), then it could be
> very difficult to detect the source of the resulting problems.

But we're talking about mixed-mode Cygwin apps.  They should use the
Win32 API with care anyway.  And the disconnection between
SetCurrentDirectory and chdir already exists if the latter is called at
all.

> [...]
> 3. The unknown.

Hard to argue aginst *that*...

> Anyway, one other detail:
> 
> Are races within a pure-Cygwin program are prevented by
> "cwd_lock"?  I don't see it being locked yet, just initialized.
> Perhaps the cwdstuff::set patch is not yet written?

There's a cwd_lock.acquire and a  cwd_lock.release call in
cwdstuff::set.  There's no such lock when cwdstuff::override_win32_cwd
is called from cwdstuff::init, because at the time init is called there's
no other concurrent thread running, except for the signal thread.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


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