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

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

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-15 21:55:11
Message-ID: 303E00EBDD07B943924382E153890E5434AA26@cuthbert.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Bruce Momjian wrote:

> In the CONNX code for kill() I see:
>     sprintf(szEventName, "CONNX_SIGNAL_%x", (int) lPID);
>     sprintf(szSharedMemoryName, "CONNX_SMEM_%x", (int) lPID);
>     hSharedMemory = OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE,
> szSharedMemoryName);
>     if (hSharedMemory) {
>         /* Call the signal handle for that process.. */
>         void           *pData = MapViewOfFile(hSharedMemory,
> FILE_MAP_ALL_ACCESS, 0, 0, sizeof(int));
>         if (pData) {
>             int             nReturn;
>             HANDLE          hProcessHandle;
>             DWORD           ExitCode;
>             *(int *) pData = nSignal;
>             UnmapViewOfFile(pData);
>             /* Open the event handle of the other process */
>             hEvent = OpenEvent(EVENT_MODIFY_STATE | SYNCHRONIZE,
> szEventName);
>             hProcessHandle = OpenProcess(PROCESS_QUERY_INFORMATION,
> lPID);
>             if (hEvent) {
>                 SetEvent(hEvent);
>                 /* Wait for Event to be processed. */
>                 do {
>                     nReturn = WaitForSingleObject(hEvent, 0);
> Now, I am no Win32 programmer, but the mixture of OpenFileMapping()
> OpenEvent() looked promising.  :-)

It's pretty straightforward: the signal is written to a shared memory
block which is qualified to a single pid.  The event is 'fired' where
presumably the other process reads the signal id from the same block and
takes appropriate action and self destructs.
WaitForSingletonObject just sleeps until the event object is 'signaled',
kind of like a handshake.  What seems a little odd to me is that there
is no timeout in this function but perhaps there is a bigger picture...?

IMNSHO it might be easier in the long run to work with message handlers
instead of events.  Map the necessary signals to messages in the WM_APP
space and broadcast them (blocking: sendmessage, nonblocking:
postmessage) with the signal in LPARAM and the pid in WPARAM, and the
'signalee' takes action following a switch.  This will minimize the
win32 API code except for implementing the callback into each backend.


pgsql-hackers-win32 by date

Next:From: Steve TibbettDate: 2003-12-15 22:19:05
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Merlin MoncureDate: 2003-12-15 21:28:34
Subject: Re: [PATCHES] fork/exec patch

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