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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

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


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
  • 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: Wed, 17 Dec 2003 10:56:05 -0500
  • Message-id: <28280(dot)1071676565(at)sss(dot)pgh(dot)pa(dot)us>

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> The difference is that if you fire the entire signal handler on the
> different thread, which means they can execute concurrently. That won't
> happen on Unix AFAIK - the main executino is stopped, right? So the
> "main thread" could change a variable while the signal handler is still
> executing - this can never happen in Unix when the signal handler
> executes, because the main thread is stopped?

Hm, good point.  There probably are some issues there for the more
complex signal handlers; they definitely assume nothing is changing
underneath them.

> 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?

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group