Why such code sometimes don't work

Such code work

Code:

---

  DWORD dwRead = 0;
  while (!dwRead)
  {
  ClearCommError(h, &Err, &ComStat);
  dwRead = ComStat.cbInQue;
  Sleep(10);
  }
  DWORD dwRead2=0;
  while (dwRead != dwRead2)
  {
  dwRead2 = dwRead;
  ClearCommError(h, &Err, &ComStat);
  dwRead = ComStat.cbInQue;
  Sleep(10);   
  }
  hb->b = true;
  return;

---

Such code sometimes don't work:

Code:

---

WaitCommEvent(h, &Mask, ReadOL);
  DWORD Signaled = WaitForSingleObject(ReadOL->hEvent, INFINITE);
  if (Signaled == WAIT_OBJECT_0)
        {
          DWORD BytesTrans;
          if (GetOverlappedResult(h, ReadOL, &BytesTrans, false))
          {
        if (Mask & EV_RXCHAR)
                  {
                    hb->ReadOL = ReadOL;
                        hb->b = true;
                        ReadFile(hComPort, buff_read, min(dwRead, 256), &tmpBytesRead, ReadOL)// Or          //                                                                                                                      NULL also don't work
//                                                                                                                        correctly...
                        CloseHandle(ReadOL->hEvent);
                }
          }
    }

---

And is it correctly to use first snippet?

The first snippet is polling, and polling is evil (since it sucks up 100% CPU doing essentially nothing) and should be avoided.

As for the second snippet, well, what does "don't work" mean? You need to explain yourself better.

In a quick look at the code, I think it is a mistake to call WaitForSingleObject unless, the call to WaitCommEvent returns a GetLastError() value of ERROR_IO_PENDING. You are calling WFSO every single time. See the final "else" branch of the sample code at http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

You might also want to use a second event that your own application sets, so you can break out of the wait loop when you want to, using WaitForMultipleObjects(), as described in the "Event Driven Approach" section of the following article: "Serial Communication in Windows" by Ashish Dhar at http://www.codeproject.com/Articles/...ion-in-Windows

Mike

doesn't work means what?

do you mean to say, sometimes it stuck in deadlock?


regards,
Vatsa
www.objectiveprogramming.com