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

> Having read through this massive thread, I concluded the
> CONNX signal stuff is the way to go. Where there any Win32
> TODO items in there? I didn't see any.

Well. There is one in the form of "make signal handlers thread-safe or
defer non-threadsafe handlers".
But before we're committed down that path, I think we need someone with
really good knowledge in those signal handlers to comment on wether this
sounsd reasonable at all, or if it iwll be too much work. I know I don't
have that knowledge, and from what I read we've had nobody speak up yet.

Basically, we want signal handlers to run on a separate thread from the
main processing.

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> Well. There is one in the form of "make signal handlers thread-safe or
> defer non-threadsafe handlers".

As long as there is only one thread that can invoke signal handlers,
I don't see why you think they need to be "thread-safe".

It's already the case that we either handle execution of a signal
handler everywhere, or block delivery of the signal where we can't
handle it, because in the Unix model a signal handler can execute
anytime.

I'd be more concerned about whether the proposed implementation accurately
models signal mask processing (ie, temporary blocking of signal delivery).

regards, tom lane

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> > Well. There is one in the form of "make signal handlers thread-safe or
> > defer non-threadsafe handlers".
>
> As long as there is only one thread that can invoke signal handlers,
> I don't see why you think they need to be "thread-safe".
>
> It's already the case that we either handle execution of a signal
> handler everywhere, or block delivery of the signal where we can't
> handle it, because in the Unix model a signal handler can execute
> anytime.
>
> I'd be more concerned about whether the proposed implementation accurately
> models signal mask processing (ie, temporary blocking of signal delivery).

On the Win32 project page:

http://momjian.postgresql.org/main/writings/pgsql/project/win32.html

I see for the CONNX driver code that handles signal masking:

/*
The sigsetmask system call replaces the set of blocked
signals totally with a new set specified in mask. Signals
are blocked if the corresponding bit in mask is a 1.
*/

int sigsetmask(int nNewMask)
{
int nPreviousMask = nGlobalSignalMask;
nGlobalSignalMask = nNewMask;
return nPreviousMask;
}

int sigmask(int nSignal)
{
return 1 << ((nSignal) - 1);
}

CONNX_signal_function CONNX_signal(int sig, CONNX_signal_function func)
{
CONNX_signal_function oldfunc;
oldfunc = CONNX_signal_array[sig];
CONNX_signal_array[sig] = func;
return oldfunc;
}

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I see for the CONNX driver code that handles signal masking:

Aren't these functions in themselves totally thread-unsafe?

That wouldn't matter in a non-thread-based implementation, but if you
are going to rely on a second thread to handle signal processing, all
of the code that manipulates the private state of the signal emulation
had better be thread-safe.

regards, tom lane