1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Fri Sep 3 16:24:00 GMT 2010
On Sep 03 12:37 Corinna Vinschen wrote:
> On Sep 2 23:32, John Carey wrote:
> > In Aug 17 10:15, Corinna Vinschen wrote:
> > > I just released 1.7.6-1.
> > ...
> > > What changed since Cygwin 1.7.5:
> > > ================================
> > >
> > > - Cygwin handles the current working directory entirely on its own. The
> > > Win32 current working directory is set to an invalid path to be out of
> > > the way. This affects calls to the Win32 file API (CreateFile, etc.).
> > > See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api
> > Thank you very much for the fix!
> > I've been running tests against Cygwin 1.7.6, and then 1.7.7,
> > and those sporadic, non-deterministic failures in CreatePipe
> > did stop after the 1.7.6 upgrade, and are still gone in 1.7.7.
> > I think it's been long enough to conclude that it is not just
> > the non-determinism--it really is fixed, as expected.
> > I understand that this issue opened a can of worms;
> > thanks again for your efforts to overcome those difficulties.
> I still don't like the final workaround, which is, to set the Win32 CWD
> to the Cygwin CWD. It would be nice if we could revert that change to
> the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out
> how to make sure that the new handle in the PEB's user parameter block
> is used even on Vista and later, pray tell me.
Thus far the only ideas I have come up with are somewhat
shaky and go well beyond the documented Win32 API.
(If only there was the equivalent of dup2(), but for Win32
handles!!!) Just how much undocumented behavior is
tolerable, do you think?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin