🚀 go-pugleaf

I wrote a serial communications component, which uses non-overlapped I/O and
creates a second thread to monitor events like the reception of a character,
parity error, etc. Here's the code for the thread's Execute() method:

void __fastcall TCOMThread::Execute()
{
    DWORD EvtMask, Errors;
    COMSTAT Status;

    SetCommMask(COMPort->PortHandle, EV_ERR | EV_RXCHAR | EV_CTS | EV_DSR);

    while (!Terminated)
    {
        WaitCommEvent(COMPort->PortHandle, &EvtMask, NULL);
        ClearCommError(COMPort->PortHandle, &Errors, &Status);

        if (EvtMask & EV_ERR)
        {
            // Handle error.
        }

        // Process other events.
    }
}

PortHandle is a private data member of TCOMPort and TCOMThread is defined as
a friend class of TCOMPort.

This code worked fine in Windows 98. In Windows NT and XP, the
WaitCommEvent() call causes not only to suspend the thread, but also to lock
the main application until one of the specified events occurs. The
application appears to hang as soon as it is started, but works 'normal'
when a constant stream of data is received. I dont't understand how a thread
can lock the application that spawned it.

Can anyone tell me what I'm doing wrong?

Regards,

Martin Nijhoff