Re: PPC 2003 Thread

Hi Tobey,

Thanks for the quick reply. I tried without changing the priority but,
it still do not signal... Any other suggetions?

Thanks again,
-Channa.

"Paul G. Tobey [eMVP]" wrote:

> You know that time-critical threads only run till completion, right? Not a
> good choice for something like this. Try it without changing thread
> priority and see what happens then.
>
> Paul T.
>
> "Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:7F513D6A-A7D3-439A-81D5-0753702568A8@xxxxxxxxxxxxxxxx
> > Hi Tobey,
> >
> > Here it is for you...
> >
> >
> > // Create a read thread for reading data from the communication port. This
> > section
> > // of code is part of one of the clsSerialControl class memeber function
> > // hReadThread and hCommPort are private member variables
> > ....
> > hReadThread = CreateThread (NULL, 0x100000, PortReadThread, this, 0,
> > &dwThreadID);
> > if(hReadThread == NULL)
> > {
> > // Could not create the read thread.
> > }
> > //Bump the thread priority up.
> > SetThreadPriority(hReadThread, THREAD_PRIORITY_TIME_CRITICAL);
> > ....
> >
> > DWORD WINAPI PortReadThread (LPVOID lpvoid)
> > {
> > BYTE Byte;
> > DWORD dwBytesTransferred,dwCommModemStatus;
> > BOOL bReadResult;
> > COMSTAT cs;
> > DWORD dwError;
> >
> > clsSerialControl *pNCP = (clsSerialControl *) lpvoid;
> >
> > while (pNCP->hCommPort != INVALID_HANDLE_VALUE)
> > {
> > // Specify a set of events to be monitored for the port.
> > SetCommMask (pNCP->hCommPort, EV_RXCHAR|EV_ERR);
> >
> > // Wait for an event to occur for the port.
> > if (WaitCommEvent(pNCP->hCommPort, &dwCommModemStatus, 0) != 0)
> > {
> > if (dwCommModemStatus & EV_RXCHAR)
> > {
> > // Loop for waiting for the data.
> > do
> > {
> > // Read the data from the serial port.
> > bReadResult = ReadFile(pNCP->hCommPort, &Byte, 1,
> > &dwBytesTransferred, 0);
> > if(bReadResult && (dwBytesTransferred == 1))
> > pNCP->gbInputBuffer.PutByte(Byte);
> > }while(bReadResult && (dwBytesTransferred == 1));
> > }
> > else
> > {
> > ClearCommError(pNCP->hCommPort,&dwError,&cs);
> > }
> > }
> > }
> >
> > ExitThread(0);
> > return 0;
> > }
> >
> > BOOL clsSerialControl::CloseCommPort()
> > {
> > DWORD dwError;
> > HANDLE hClosePort;
> >
> > if (hCommPort != INVALID_HANDLE_VALUE)
> > {
> > hClosePort = hCommPort;
> > hCommPort = INVALID_HANDLE_VALUE;
> >
> > // Close the communication port.
> > if (!CloseHandle (hClosePort))
> > {
> > dwError = GetLastError ();
> > return FALSE;
> > }
> > WaitForSingleObject(hReadThread, INFINITE);
> > }
> > return TRUE;
> > }
> >
> > Thanks,
> > -Channa.
> >
> > "Paul G. Tobey [eMVP]" wrote:
> >
> >> At a guess, because you're waiting on the wrong handle. Show us a 30
> >> line
> >> or less sample, including the thread procedure, which demonstrates the
> >> problem.
> >>
> >> Paul T.
> >>
> >> "Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:F24C0CD4-49AA-4C6F-BBF9-2A5A39AD1A67@xxxxxxxxxxxxxxxx
> >> > Hi,
> >> >
> >> > I have an app created originally for PPC 2002 using eVC++ v3.0 and,
> >> > it
> >> > has been migrated to PPC 2003 platform using eVC++ v4.0.
> >> >
> >> > I have been noticing some odd behaviour since recently, and thought
> >> > of
> >> > asking if anybody else have experienced the same and worked around
> >> > already? I
> >> > have a separate thread reading the COM port. I am noticing that
> >> > although
> >> > this
> >> > thread exit normally, the main process do not get signaled state (using
> >> > WaitForSingleObject INFINITEly)!
> >> >
> >> > I did trace using Kernel Tracker tool and noticed that the two
> >> > threads
> >> > (main- and the COM-port-reading-thread) got blocked. I used to use
> >> > "return"
> >> > for exiting the COM port reading thread. So, I changed it to
> >> > ExitThread(),
> >> > and now, the COM port reading thread get terminated but the main
> >> > process
> >> > do
> >> > not get signaled and the Kernel Tracker tool shows that my main thread
> >> > is
> >> > still being blocked. I have no idea is to why?
> >> >
> >> > Any input would be appreciated.
> >> > Thanks in advance,
> >> > -Channa.
> >> >
> >>
> >>
> >>
>
>
>
.