Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)
Date: 2003-12-19 13:44:45
Message-ID: 303E00EBDD07B943924382E153890E5434AA36@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

Zeugswetter Andreas wrote:
> > The issue at hand is not how the signal is sent, but the behavior
taken
> > once it arrives. Using messages bypasses the thread problem but
> > requires PeekMessage() to be put in various places to check if there
is
> > a signal waiting to be acted on, which is really any easier then
> > SleepEx(0), although, it does bypass the threading issues.
>
> I think that is not correct.
>
> hWnd = CreateWindow ("STATIC", "", WS_POPUP, 0, 0, 0,
[...]

The question is: is the event procedure running in the main thread or a
separate worker thread.

If it is in the main thread the signal event will not fire until the
thread sleeps or explicitly checks for waiting signal messages via
PeekMessage(). This also means working the callback into the main
backend loop.

If it is in a separate worker thread, of course the signal event will
fire immediately but execution of the main thread is not suspended,
unlike unix signals which suspend execution of the program. This could
lead to very subtle and difficult to understand behavior unless every
signal routine can be 100% certified to run parallel to the main
execution line. There are a couple of different ways to suspend a
thread from another thread (without true synchronization), each with
inherent problems.

Therefore, a message handler differs from normal thread synchronization
in the following ways:
1. The message pump does not necessarily have to be in a separate
thread, resulting in threadless operation.
2. The message contains both the notification and the signal itself,
removing the need to used shared memory to hold the message (as in your
example).
3. The message is not very secure. They can come from other processes
than the postmaster.
4. When run as a service, the freedom to broadcast and receive messages
is restricted. This restriction can be lifted, but this will be an
unpopular decision with win32 admins. Do a search on 'service interact
desktop'.

The main reason it does not differ from a worker thread based signal
handler using synchronization objects is does get you out have having to
poll the worker thread from the main thread periodically to see if a
signal has fired. This, of course is the major sticking point unless
signal handlers can be certified to be thread safe; not just structural
thread safety, but a more general 'do the same thing regardless if the
main thread has been suspended or not'.

Merlin

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Magnus Hagander 2003-12-19 19:45:56 Signals on Win32 (yet again)
Previous Message Zeugswetter Andreas SB SD 2003-12-19 10:00:47 Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)