On 12/21/2012 05:23 PM, marco atzeri wrote:
On 12/21/2012 8:36 PM, Christopher Faylor wrote:
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 was worried about this possibility after looking at the code changes.
But, I haven't had to a chance to test adequately yet. I would expect
indefinite blocking in dll_entry() may prevent unloading DLLs. For
example, calls to dll_entry() for DLL_PROCESS_DETACH may get blocked.
It looks to me like the changes made are insufficient to prevent the
race. For example, this won't address the case where an exiting thread
releases the process lock acquired in dll_entry() before a thread
exiting the process acquires it in pinfo::exit(). Both threads could
still end up in an ExitThread() vs ExitProcess()/TerminateProcess()
race. However, this is only true for threads whose exits are not
predicated upon an action taken by the process exiting thread after it
has acquired the process lock in pinfo::exit(). And since the exiting
thread must be the last thread of the process in order to hit the issue,
this may not be a concern.
I'm not sure that a general workaround for this issue is feasible for
all possible threads. At least, not without hooking the Terminate* and
Exit* Win32 APIs. My gut tells me that a general solution requires
waiting for thread handles to be signaled, but I haven't thought it
completely through yet.
It looks like Chris reverted the change and checked in a new update. I
haven't looked at those changes yet.
Tom.
--
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
