They seem to be thread-unsafe, yes, but that can be fixed pretty easy
(and probably should).
The difference is that if you fire the entire signal handler on the
different thread, which means they can execute concurrently. That won't
happen on Unix AFAIK - the main executino is stopped, right? So the
"main thread" could change a variable while the signal handler is still
executing - this can never happen in Unix when the signal handler
executes, because the main thread is stopped?
An option would be to SuspendThread() on the main thread, which freezes
it completely durnig the execution of the signal. If necessary, are we
safe against that? (Basically, SuspendThread() will suspend a thread
even if it's inside a kernel call.
//Magnus
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Wednesday, December 17, 2003 4:36 PM
> To: Bruce Momjian
> Cc: Magnus Hagander; pgsql-hackers-win32
> Subject: Re: [pgsql-hackers-win32] [HACKERS] [PATCHES]
> fork/exec patch
>
>
> Bruce Momjian <pgman@candle.pha.pa.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
>