valgrind for WINE

[Alexandre Julliard]

Adam Gundy <arg at cyberscience.com> writes:

> it's not guaranteed to be immediate on UP either - harder to trigger, but suppose
> other signals are pending for the thread to be suspended; they could be handled first...
> 
> since we block SIGUSR1 delivery during client/server interaction , the thread to be
> suspended could wait a (potentially) long time before it is suspended.

It isn't executing any application code, that is what is
important. From the point of view of the app a signal handler or a
server call is just like a system call, it isn't running actual code.

> anything? there is a very small chance that _another_ thread will suspend or kill the
> responsible thread before it can send the signal. code that does that won't work reliably
> anyway, since the second suspend could just have easily have happened before the first.

But that's not a problem, because the thread won't have been suspended
at all. The problem is not that the app is broken, it may well be but
there's nothing we can do about it. The problem is that the server
state must be consistent with what is actually happening in the
client.

> can you honestly come up with a case where this change is going to affect anyone??
> the only code I can think of that might behave differently is if someone is trying to
> do thread synchronization using SuspendThread - which Microsoft explicitly say won't work...

What Microsoft say doesn't matter; what matters is what applications
do. Many apps use SuspendThread, and it has to work reliably 100% of
the time, not just 99%. It's the same argument we had with mutexes,
and shared memory, etc.  Sure you can simplify a lot of things if you
don't try to handle "unlikely" cases; but practice has shown that no
matter how unlikely a case may seem, there is a Windows app out there
that triggers it. And we want to run *all* Windows apps, not just the
ones that are lucky enough to not trigger our bugs.

> if you are really worried about the above case, we could block SIGUSR1/SIGKILL for the
> duration of the suspendthread client/server interaction - we already block these signals
> during 'wine_server_call()' - it's just a case of extending this blocking around the other
> code in SuspendThread().

You can't block SIGKILL, or SIGSTOP, or seg faults, or whatever else
could happen in there. The design principle of the wineserver is that
it should be reliable no matter how broken the client is.

-- 
Alexandre Julliard
julliard at winehq.com