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