On 12/21/2012 11:36 AM, Christopher Faylor wrote: > On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote: >> On Dec 21 11:10, Christopher Faylor wrote: >>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote: >>>> Maybe the signal thread should really not exit by itself, but just >>>> wait until the TerminateThread is called. Chris? >>> >>> If the analysis is correct, that just fixes one symptom doesn't it? >>> There are potentially many threads running in any Cygwin program >>> and it sounds like any one of them could trigger this. >> >> Right. I guess the question is how to synchronize things so that the >> thread calling TerminateProcess is actually the last one, making sure >> its return value is used. >> >> Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some >> help. Or we have to keep all thread IDs of the self-started threads >> available to terminate them explicitely at process exit. > > I checked in a complicated fix for this problem which only affected > Cygwin-created threads. But, then, I thought about another riskier but > simpler fix.
Your second approach scares me. There's no global order imposed on the loader lock and the Cygwin process lock, and Windows can take the loader lock at virtually any time, since LoadLibrary can be used internally to implement any API.
signature.asc
Description: OpenPGP digital signature
