Re: Win32 signal code - first try
От | Merlin Moncure |
---|---|
Тема | Re: Win32 signal code - first try |
Дата | |
Msg-id | 303E00EBDD07B943924382E153890E5434AA47@cuthbert.rcsinc.local обсуждение исходный текст |
Список | pgsql-hackers-win32 |
Claudio, 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 PG_SETMASK(&BlockSig);) b. once non-blocked, execute QueueUserAPC c. terminate 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/ AuthBlockSig 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? Merlin
В списке pgsql-hackers-win32 по дате отправления: