Forget what I said about an array of handles. Looking at postgres's
sources, it seems signals are not handled as masks, but as logical
blocks. (the Starship Enterprise model, 'shields up!'). Only one event
handle is needed for each logical block of signals (there are only two
that I can see). I searched and there are no explicit calls to
sigsetblock in the sources except for the Darwin port. (shows what a pg
newbie I am by not knowing all this already).
To summarize my opinion of how things should go:
1. Named pipe server creates new thread on receipt of signal
2. Thread created by named pipe does following:
a. check state of event object (set to 'blocked' in
b. once non-blocked, execute QueueUserAPC
3. Two (manual) events per backend, one for BlockSig signal block, one
for AuthBlockSig. Not 32 or whatever the signal table size is. Now we
have a somewhat elegant implementation that closely follows the normal
api. Only a slight modification of Magnus's initial design.
Safety could be enforced by PG_SETMASK(*) and WFSO + QueueUserAPC
sharing a critical section if necessary.
Rough summary of implementation into the main sources:
1. need to write WIN32 versions of the PG_SETMASK macro.
2. need to find/write function resolving specific signal to BlockSig/
3. need to figure out how to interrupt the main backend command
processing loop to handle a signal. This currently has me stumped :(
4. need to convert 'poll' function to a macro, IMO.
5. need to identify strategic polling points in the backend.
Question: how come all the pqsignal files are in the libpq folders?
pgsql-hackers-win32 by date
|Next:||From: Bruce Momjian||Date: 2004-01-09 21:08:12|
|Subject: Re: [PATCHES] pg_usleep|
|Previous:||From: Chetan R Deshpande||Date: 2004-01-09 17:06:34|