Обсуждение: 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
"Magnus Hagander" <mha@sollentuna.net> writes: >>> 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? >> >> Why would that be a 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. Hmm. Sounds like SuspendThread is not a workable option at all. regards, tom lane