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,
FALSE,
> szEventName);
> hProcessHandle = OpenProcess(PROCESS_QUERY_INFORMATION,
FALSE,
> 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()
and
> 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.
Merlin