> 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.
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?
Of course, I may have missed something completely as well :-)
//Magnus