RE: FW: cygwin-1.dll long-time bug

["Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>]

> From: Dave Korn
> Sent: Tuesday, April 18, 2006 1:39 PM
> To: 'tricksy codes'
> Subject: RE: FW: cygwin-1.dll long-time bug
> 
> On 18 April 2006 19:26, Christopher Faylor wrote:
> 
> > On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
> >> where Mark Russinovich says
> >> 
> >> "As for the issues looking at threads, the problem is a Cygwin 
> >> behavior that's incompatible with the Windows API, 
> >> RtlQueryProcessDebugInformation, that Process Explorer 
> uses to obtain 
> >> the list of modules loaded into a process.  That API 
> injects a thread 
> >> into the remote process to query the loader data structures.  The 
> >> target process DLLs get a DLL_THREAD_ATTACH notification, which 
> >> causes some Cygwin DLL thread to hang and the 
> >> RtlQueryProcessDebugInformation to never return."
> > 
> > So, rather than saying "I wonder why Cygwin would hang when 
> a thread 
> > is injected?" the conclusion is that "Cygwin behavior which is 
> > incompatible with the Windows API" and the fix is to 
> "thread injection gracefully".
> > 
> > I don't see what more there is to say on the subject.  Clearly with 
> > just a little more grace, Cygwin's problems would be solved.
> > 
> > cgf
> 
> 
>   Well, I think it's reasonable enough to say that cygwin 
> does things that are pushing the envelope of what's 
> documented to work in relation to how we handle forking and 
> process startup.  After all we just had that lockup caused by 
> the fact that you can't even call GetModuleName[*] from 
> DllMain safely.  Things happen in an unusual order in cygwin 
> processes and threads, and it's probably not something that 
> gets a whole load of testing in microsoft's QA dept.... ;)
> 
> 
>     cheers,
>       DaveK
> 

WHOAH WHOAH WHOAH there Korns, don't take personal offense!  Sheesh!  It's
getting to be a regular minefield in here!

-- 
Gary R. Van Sickle