Re: Can we simplify win32 threading code

> I have simplified the code according to the discussion. Now
> there is no pipe or signaling threads, process access shared
> memory directly to pass signals.
> Seems everything works fine except pg_ctl. I now have two
> choices to fix it:
>
> (1) Record Shared memory name (it is already there) and the
> offset of signaling shared memory in postmaster.pid; So the
> pg_ctl program can access the shared memory (since it has
> write down the signal number there) and SetEvent target process;

Why not just use the pid in teh name, and have one segment per backend?
Remember on Win32 having a couple of hundred shared memory segments is
not a problem. (I assume you are creating these using MapViewOfFile()
etc, and not using the shmget() emulators)

Then if I want to kill pid 1234 I just do:
mtx = OpenMutex(..,"pqsignalmtx1234");
WaitForSingleObject(mtx);
m = OpenFileMapping(...,"pqsignal1234");
v = MapViewOfFile();
-- write signal number --
UnmapViewOfFile(v);
CloseHandle(m);
e = OpenEvent(..,"pqsignalevt1234");
SetEvent(e);
CloseHandle(e);
ReleaseMutex(mtx);
CloseHandle(mtx);

(pseudo-code. You'll need to look for deadlocks in the event processor,
but it should be fairly easy to write code that won't deadlock)



>
> (2) Postmaster will startup a thread monitoring messages,
> pg_ctl simulate "kill" by sending postmaster a message
> <target_pid, signum>, then postmaster will forward this
> "signum" to "target_pid";

I don't like that. If the postmaster dies, how will you signal the
remaining backends? The signal processing has to take place in the
actual backend affected, and only there. But that should be no problem
with the solution I outlined above.

This way you'll also be able to pg_kill a process without knowing where
the postmaster.pid file is, which at least I would expect. Needing to
specify the full data path just to run pg_kill is not good.

//Magnus