valgrind for WINE

[Adam Gundy]

At 10:15 03/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <arg at cyberscience.com> 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.