Re: [HACKERS] [PATCHES] fork/exec patch

>Yep, I think that you are right again on all counts.  So far I gather:
>
>1. postmaster will IPC backends via pipes named, sending signal value.
>2. pipe server starts thread inside backend process which:
>2a. executes signal action if signal action can be confirmed to be
>thread safe
>or
>2b. signals backend main thread to stop what its doing and take signal
>action, which requires injection of polling at certain places in the
>backend code.
>3. once backend main thread is alerted or signal action is completed,
>the signal alter thread terminates.
>
>so, the communication from postmaster to a backend is asynchronous, but
>from the 'alert' thread to the backend main thread is synchronous.

Yup, that's what I'm thinking.


>What's interesting about '2b', despite being a less attractive option
>from an implementation point of view, is that SleepEx() wakes up
>following an APC or asynchronous I/O.  In fact, SleepEx() is designed
>for a thread to hang out and wait for I/O to complete.  Since backends
>are almost always either sleeping or doing I/O, this would help relieve
>the burden on polling.  Probably though it would be better to engineer
>signal handlers to be threadsafe if at all possible.

There is one thing missing in that line of discussion. It only works if
you use Win32 Async I/O (Overlapped I/O or I/O completion ports),
AFAICS. That would mean rewriting the storage layer both into using
win32 function and into being async. I think that's a bit more work than
we're asking for here.

(My test specifically showed that using fread() (thus, almost certainly
read()) does not cause any of the required functions to be called)

So I think the signal handlers is where to look.

Do we have any authoritive information on the current level of
thread-safeness of the signal handlers? Or anyone with an idea on about
how much work it would take (I have to admit I haven't even counted how
many there are...)


Oh, and don't forget that the postmaster will require it's own "signal
thread", since backends can use signals to send info back to the
postmaster. You could use the same pipe backwards, but it's definitly
cleaner from an implementation point of view to use the exact same code.


//Magnus


BTW, for the record, here is a quick view of how to make actual
interrupting calls into another thread. I think you can see why I do't
think that's a really good option..

When calling the signal, run:
SuspendThread(mainThread);
GetThreadContext(mainThread);