Re: Win32 signal code - first try
От | Merlin Moncure |
---|---|
Тема | Re: Win32 signal code - first try |
Дата | |
Msg-id | 303E00EBDD07B943924382E153890E5434AA4C@cuthbert.rcsinc.local обсуждение исходный текст |
Список | pgsql-hackers-win32 |
Magnus Hagander wrote: > That should be safe, IMHO. I was looking at getting rid of the "Everyone > else" part, I'd like to avoid having to create our own security > descriptors if possible. If we want to be NT4 compatible, we can't use > the "easy" functinos to build them. Nor can we use ATL, since we are in > C and not C++. hm. maybe this needs some more thought. I don't know much about NT security unfortunately. > > 2. How does a sleeping backend (waiting on command) get > > interrupted so that it handles a signal? > My idea was by using WaitFor..Ex() with alertable=true. Yes, this fine for polling, but what about when the backend is *sleeping*? As I understand the backend main processing loop, (and my understanding is far from complete...) the backend waits on 'read from socket' when it is not doing anything. Correct me if I'm wrong, but this is not interruptible from an APC. I could be way off in left field here, but what I'm looking for is for someone to confirm that signals can be received when a backend is waiting for a command (perhaps a timeout has to be inserted?). > Looking at your security question above, it could possibly be an issue > if someone in the "everyone else" group connected with read access only, > and never sent anything. Which would be avoided with the separate thread > doing the read as well. Well, my instincts are to leave the ReadFile where it is unless there is no other way. Reading the signals from the file (pipe) is by nature a synchronous operation. > > I suggest reconsidering an event managed from within the main > > backend thread to do signal blocking, in combination with the > > bitmask you guys suggested to do filtering. > Why is this necessary, specifically? I'm not fully in on that :-) As > long as the bitmask of blocked signals (and queued ones) are protected > with a crit sect? The answer is that this keeps us from having to keep track of 'queued' signals...the OS does this for us. We only have to maintain a list of pending signals to potentially block multiple signals of the same type. Postgres has two modes of operation, 'shields up' and 'shields down'. Inside PG_SETMASK, we set the event flag to 'not signalled', meaning pg_queue_signal must check the blockmask first, and if the signal is blocked, stall the signal through the event until it is let go (PG_SETMASK(&UnBlockSig);). This is a vast simplification of the handling that takes advantage of two properties of postgres's signal handling: 1. Signals are manipulated as a group, the blockmask is never manipulated directly in code. 2. The signal group does not chang without being brought down first. As long as these two properties are true, we can use a single event to handle all blocked (queued) signals. To my way of thinking, this is a much cleaner implementation and follows pg's overall signaling model. It will simplify the code that executes when the blockmask comes down. Merlin
В списке pgsql-hackers-win32 по дате отправления: