Skip site navigation (1) Skip section navigation (2)

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

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-17 16:36:19
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE17157C@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
> > 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

Responses

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2003-12-17 16:45:44
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Merlin MoncureDate: 2003-12-17 16:09:15
Subject: Re: [HACKERS] [PATCHES] fork/exec patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group