On Fri, Dec 21, 2012 at 11:23:00PM +0100, marco atzeri wrote: >On 12/21/2012 8:36 PM, 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. That version is now in CVS and I'm generating a new >> snapshot with it. >> >> I tested this lightly on Windows 7 and 32-bit XP but it would be nice to >> hear if multi-threaded things like X work on other platforms too. >> >> If you test a snapshot, note that I'm still tracking down Ken Brown's >> reporte emacs regression in recent snapshots so that will still be >> broken. >> >> cgf >> > >I think the Xserver doesn't like it. >on 20121221 it freezes on start on W7/64 >no issue on 20121218
I acdtually tried Xserver before submitting my change so it certainly isn't a consistent problem. cgf -- 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