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

Re: Win32 question: getppid() with no parent?

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PgSql-Win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 question: getppid() with no parent?
Date: 2004-05-27 18:00:39
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE1716A4@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
>On Unix, it is possible to tell whether your parent process has died
>by checking to see if you have become a child of init:
>
>	if (getppid() == 1)
>	   /* oh dear, I am an orphan */
>
>Is there equivalent functionality available on Windows?
>
>Currently, we have the pgstat child process checking for postmaster
>death by watching for read-ready on a pipe.  This does not scale
>pleasantly to multiple long-lived postmaster children, though, so
>I'm wondering about ways for the children to detect a postmaster crash
>without requiring any direct postmaster cooperation.

Not really.
http://www.codeguru.com/Cpp/W-P/win32/article.php/c1437/
Can be done, but that's really ugly.

Question though - we keep a PostmasterPid variable, right? One way to do
it is if we n child startup do OpenProcess() on this pid, to return a
HANDLE (the pid may be reused, but an open handle certainly can't). We
can then do a simple:
if (WaitForSingleObject(PostmasterHandle, 0) == WAIT_OBJECT_0)
   /* oh dear, postmaster is gone */

This exepects that we know whom our parent is at process start, which
gettpid doesn't. But it might be enough?


(If we can't rely on that variable, we could do a win32 specific hack
that passes the HANDLE of the postmaster down to the child on exec, I
guess.)

//Magnus

Responses

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-05-27 18:04:52
Subject: Re: Win32 question: getppid() with no parent?
Previous:From: Tom LaneDate: 2004-05-27 17:40:40
Subject: Win32 question: getppid() with no parent?

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