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

Magnus Hagander wrote:
> Oh yeah, this is all beside the point if either
> a) The signal handlers are already thread-safe (after all, the CONNX
> guys called it on a different thread. Did they change anything in the
> actual signal handlers, that we know of?)
> b) The signal handlers *can be made* thread-safe fairly easy (no need
> for re-entrant, but any variable access needs to be synchronized)

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.

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.

Merlin