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: (view raw, whole thread or download thread mbox)
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:

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:

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.



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-2017 The PostgreSQL Global Development Group