At 10:15 03/04/03 -0800, Alexandre Julliard wrote: >Adam Gundy <[EMAIL PROTECTED]> writes: > >> anything that uses SuspendThread is inherently racy and unpleasant. Even the >> Microsoft >> documentation says "don't use this!". Of course, they ignore themselves and do it >> (twice) >> during MFC thread creation, but... >> >> We aren't currently adding _any_ race condition that isn't already there - the >> wineserver >> sends a signal to the client process in the current code - who knows when that will >> be delivered? >> there could be a big gap between the server sending the signal, and the signal >> being processed. > >There may be a delay, but the thread is still effectively suspended >since it's not running any user-mode code. The signal will get >delivered on the next switch to that thread, so we still get the >correct behavior. If the signal is sent in the client the suspended >thread can still run arbitrary amounts of code while the server >believes it is already suspended.
you can't reason like this - it all falls apart with SMP. Both threads can happily be running at the same time - we are using clone() after all. I can currently produce this race (without my patch applied) by adding a "Sleep( 1000 )" to the USR1 signal handler in ntdll/signal_i386.c. The wineserver is convinced that the thread is suspended, but it isn't (sleeping is a bad example - assume that a context switch occurred, or heavy processing happened before the signal was delivered). this 'race' doesn't have ANY effect, because suspending a thread is not a precise operation - it doesn't matter whether 1 or 1000 instructions are executed by the thread before it stops. Windows threads don't give guarantees about thread suspension (unlike pthreads). to summarize: a) there is already a race condition in the current code - it _probably_ only triggers on SMP or heavily loaded UP. b) my patch won't make things any worse c) the race doesn't matter because Windows threads don't guarantee what happens when a thread is suspended (read Microsoft's docs - they practically say "don't use this call" for this very reason). Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
