Bruce Momjian wrote:
Have you looked at the CONNX signal code on the Win32 page:
http://momjian.postgresql.org/main/writings/pgsql/win32.html
It uses shared memory and events.
Yes, and I just did again. I guess I must be missing something, though - I don't see what in that code causes the signalled process to call the handler corresponding to the signal. Maybe I'm just a little brain dead today ...
Can't find that part either, but a few questions for the implementation regardless of wether that code is around somewhere:
At what times do signals actually *need* to be delivered? And at what points do the calling process need to be notified?
Actually interrupting a running process to execute a procedure in a thread can be pretty darn tricky - AFAIK you have to manually switch thread context and create an exception which you then catch, call handler, reset and continue.
However, if it's acceptable to have delivery only when the thread is in "alertable state" this should not be necessary. Then you can basically take two approaches depending on when you need the response:
If you just need a response that the receiving process has queued the thread handler, then create a separate thread that receives the signal and queues a user APC on the main thread. This will then execute when the thread enters alertable state.
Actually, I see that in os-fix2.cpp there is code that sets up a thread that just polls for the event and then calls the corresponding handler.
If you need a response once it has actually run, then the main thread needs to do signal polling now and then. This has the bad sideeffect that the main thread will block completely until the signal is delivered, which might be a while.
I don't know what the semantics are for kill() on unix there? And if it is sync, does postgresql actually need that property?
kill() should return success upon the signal being queued, as I understand it - i.e. no sync.
All this kind of answers my original question, by pointing out the need to poll one way or another, which is why I suggested that signal emulation might be messy, and more complicated than the fork/exec case.
In effect, the runtime in Unix provides the signal polling for you for free, which is why this method of IPC is so commonly used.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
