> 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

Tue, 16 Dec 2003 11:09:03 +0100
"Magnus Hagander" <mha@sollentuna.net>
Re: [HACKERS] [PATCHES] fork/exec patch
Magnus Hagander wrote:
>>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


Tue, 16 Dec 2003 09:56:19 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] [PATCHES] fork/exec patch