On Sun, Mar 01, 2009 at 10:25:32PM +0000, David Laight 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!)
Nope. If newThreadFun runs before the main thread checks flag, it sets the flag and spins waiting for messages (with no visible window or other way I know of to get messages) and the main thread spins on sleep.
If newThreadFun runs after mainthread has passed the sleep check, it sets the flag and spins waiting for messages with no visible window. However, the main thread pops up a window, and later on unhides the thread's window (or tells the thread to do it. I don't know exactly).
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.
Not that I could replicate, on my Core2Duo laptop running XP x64.
So I'd guess that warpatch.bin or broken.
That's my guess, but it'd be nice to be able to say for sure before I chase it up with Mythic, given that it's taken two weeks for the last issue I raised with them to get elevated to someone who didn't suggest I create my Windows XP Administrator account and resend them another dxdiag.