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

>> > How about the typical answer on Windows ? Create an
>invisible Window
>> > with an Event Handler and pass it a windows message ?
>>
>> 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, 0,NULL,NULL,NULL,NULL);
>            ShowWindow (hWnd, SW_HIDE);
>        wpOrigProc = (WNDPROC) SetWindowLong(hWnd,
>GWL_WNDPROC, (LONG) pg_WinProc);
>
>LRESULT APIENTRY pg_WinProc(
>    HWND hwnd,
>    UINT uMsg,
>    WPARAM wParam,
>    LPARAM lParam)
>{
>    MSG rMsg;
>
>    rMsg.message = uMsg;
>    rMsg.wParam = wParam;
>    rMsg.lParam = lParam;
>
>        // printf ("got message %d\n", rMsg.message);
>    switch (rMsg.message)
>    {
>        case PG_SIGNAL_KILL:
>    ......
>}


I'm quite sure he is correct. The documentation on MSDN clearly states:
[1] "An application must remove and process messages posted to the
message queues of its threads. A single-threaded application usually
uses a message loop in its WinMain function to remove and send messages
to the appropriate window procedures for processing. Applications with
multiple threads can include a message loop in each thread that creates
a window."


That message loops generally looks like:
while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
    {
        if (bRet == -1)
        {
            // handle the error and possibly exit
        }
        else
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }


This has to be running on the thread that owns the window. Which in this
case would be the main thread of the backend, meaning it buys us
nothing.


A typical "proof" of this: The "hanging GUI" application. This is an
application that's doing other things than working it's message loop. In
that case, it can't even redraw the screen, because it can't see the
messages. The other option would be a threaded application that lock
itself out, but most of the applications that experience that problem is
not threaded. Indeed, MS recommends you create a background thread for
longer work for just this reason - to have the main thread run the
message loop.
This is slighly worked around in XP to make programs appear live even
when they're not, see [1].


//Magnus

[1]:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/w
inui/windowsuserinterface/windowing/messagesandmessagequeues/aboutmessag
esandmessagequeues.asp