Re: [HACKERS] [PATCHES] fork/exec patch

> > An option would be to SuspendThread() on the main thread, which
> > freezes it completely durnig the execution of the signal. If
> > necessary, are we safe against that? (Basically,
> SuspendThread() will
> > suspend a thread even if it's inside a kernel call.
>
> Why would that be a problem?

I read something about this the other day :) Check:
http://blogs.gotdotnet.com/raymondc/commentview.aspx/f4300961-3a9d-4c4d-
977f-1d10e90b95f0

Specifically:
The same logic applies to Win32 or any other threading model. In Win32,
the process heap is a threadsafe object, and since it's hard to do very
much in Win32 at all without accessing the heap, suspending a thread in
Win32 has a very high chance of deadlocking your process.


That is the problem.

In a nutshell: If the main thread holds a lock on something we need
(such as the heap), we just shot ourselves in the foot.

A few more references:
http://groups.google.se/groups?q=suspendthread+deadlock&hl=en&lr=&ie=UTF
-8&oe=UTF-8&selm=Xns93656F92DE661JochenKalmbachholzma%40127.0.0.1&rnum=1
http://groups.google.se/groups?q=suspendthread+deadlock&hl=en&lr=&ie=UTF
-8&oe=UTF-8&selm=3638FEE4.E03FB328%40tektronix.com&rnum=4
http://groups.google.se/groups?q=suspendthread+deadlock&start=10&hl=en&l
r=&ie=UTF-8&oe=UTF-8&selm=d6h1st4rhnt0flq29k752fusds6iib3n6i%404ax.com&r
num=18


MSDN documentation has this to say:
This function is primarily designed for use by debuggers. It is not
intended to be used for thread synchronization. Calling SuspendThread on
a thread that owns a synchronization object, such as a mutex or critical
section, can lead to a deadlock if the calling thread tries to obtain a
synchronization object owned by a suspended thread. To avoid this
situation, a thread within an application that is not a debugger should
signal the other thread to suspend itself. The target thread must be
designed to watch for this signal and respond appropriately.


//Magnus