C / C++ / MFC

Chuck O'Toole wrote:

Sleep() adds code to the loop,

Chuck O'Toole wrote:

even with Sleep(0) to quit the timeslice, still causes a complete scheduler
cycle to look for other runnable threads before returning to this thread.

Chuck O'Toole wrote:

Clearly Sleep() adds code for *no benefit to this application* whereas
*Peek/translate/dispatch* are *beneficial* to this app.

Chuck O'Toole wrote:

He's not getting back to his message pump *because* he's doing processing in his
GUI handler. Sleep ain't gonna help that because there's no Message Pump to run

Chuck O'Toole wrote:

there's no Message Pump to run. Period. He has to provide his own

Erudite__Eric wrote:

Of course there is! He wouldnt HAVE a Windows applicaiton without a message
pump!

void CRegressionTesterDlg::ProcessWindowMessages()
{
    MSG msg;

//  Sleep(0);
    while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))  // let them see the message before we go into longer term wait
    {
        TranslateMessage(&msg);                         // translate it
        DispatchMessage(&msg);                          // and let windows dispatch it to WinProc
    }
}

Occasionally, an application needs to examine the contents of a thread's message queue from outside the thread's message loop. For example, if an application's window procedure performs a lengthy drawing operation, you may want the user to be able to interrupt the operation. Unless your application periodically examines the message queue during the operation for mouse and keyboard messages, it will not respond to user input until after the operation has completed. The reason for this is that the DispatchMessage function in the thread's message loop does not return until the window procedure finishes processing a message.

You can use the PeekMessage function to examine a message queue during a lengthy operation. PeekMessage is similar to the GetMessage function; both check a message queue for a message that matches the filter criteria and then copy the message to an MSG structure. The main difference between the two functions is that GetMessage does not return until a message matching the filter criteria is placed in the queue, whereas PeekMessage returns immediately regardless of whether a message is in the queue.

The following example shows how to use PeekMessage to examine a message queue for mouse clicks and keyboard input during a lengthy operation.

Chuck O'Toole wrote:

Whatever gave you that impression?

Chuck O'Toole wrote:

So, I think that Sleep() does not do as you assert, it has no effect on the Windows Message Processing. Furthermore, Microsoft's documentation on Sleep() explicitly warns against using it during functions called by message processing as it may cause a hang or delay in processing.

Chuck O'Toole wrote:

PeekMessage() allows your GUI to be "responsive" incase the user clicks on something

Mark Salsbery

Mark Salsbery wrote:

Waiting on I/O should be done on separate thread(s)

// Set Timeout 50 ms
mi_Socket.Listen(0, ms32_Port, 50);

while (...) // This loop runs in the GUI thread
{
    PumpMessages(); // process Windows messages
       
    DWORD u32_Event;
    SOCKET  h_Socket;
    // ProcessEvents() returns after 50 ms or after an event was received
    DWORD u32_Error = mi_Socket.ProcessEvents(&u32_Event, &h_Socket, ....);

    if (u32_Error == ERROR_TIMEOUT)
        continue;

    if (u32_Event & FD_ACCEPT) { /* A new client has connected */ }
    if (u32_Event & FD_READ)   { /* Data has been received */ }
    if (u32_Event & FD_CLOSE)  { /* A socket has closed */ }

    if (u32_Error) { /* handle error */ }
};