On Mon, Mar 2, 2009 at 12:25 AM, David Laight david@l8s.co.uk wrote:
On Sun, Mar 01, 2009 at 06:08:53PM +1100, Paul TBBle Hampson wrote:
I'm looking into Bug 15323, and it seems to come down to a particular undocumented behaviour of CreateThread on Windows, which is probably also a bug in the usage of it by warpatch.bin, the Warhammer Online patcher.
Problem code outline: Main thread: flag = false; createThread( newThreadFun ) sleep until flag = false;
newThreadFun: flag = true CreateHiddenWindowAndWaitForMessageFromMainThread; flag = false; return;
On inspection, the only way this can work is if the main thread's "sleep until" test is done before newThreadFun gets started.
Isn't that backwards? Doesn't the above rely on the new thread pre-empting the main thread? (The above example seems to be implementing a function call!)
In any case the above example is doomed to failure. I don't expect that windows defines which thread runs first. And on a multi-processor system they are likely to both run.
So I'd guess that warpatch.bin or broken.
David
-- David Laight: david@l8s.co.uk
Msdn sayes: "The ExitProcess, ExitThread, CreateThread, CreateRemoteThread functions, and a process that is starting (as the result of a call by CreateProcess) are serialized between each other within a process. Only one of these events can happen in an address space at a time. This means that the following restrictions hold:
* During process startup and DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process. * Only one thread in a process can be in a DLL initialization or detach routine at a time. * ExitProcess does not complete until there are no threads in their DLL initialization or detach routines."
So maybe this hidden synchronization is causing also newly created thread not to run until CreateThread has exited.
Does wine even follow these document restrictions?