Re: PPC 2003 Thread
- From: Channa <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Apr 2005 17:02:03 -0700
Hi Tobey,
Sorry for the confusion. Let me explain more...
What I mean by same executable is that, actually, I am using eVC++ v4.0
IDE to create a single executable (for wce300) so that the same executable
could run on both PPC 2002 and PPC 2003. However, I tested the executables
created for wce300 and wce420 (out of the same source code base) on PPC 2003,
but the problem persists.
As to your second concern, "yes" I did single stepping through and also
sending debug strings to a text file to indicate what point in the thread
code that it waas last executed before the lockup, as well. The phrase that
you quoted was reffering to the instance that I was single stepping through
the thread function -- you were correct. Hope this helps for you to determine
what I did and what you wanted me to try. Please, if you have more
suggestions, let me know.
I am not familiar with what you mean by send the handle value to debug
port, etc. please explain more as to how can I do that? I think that would be
a valuable test to do. So, please help.
"Paul G. Tobey [eMVP]" wrote:
> Wait!!!! The "same EXECUTABLE" runs on PPC2002? I don't think so, if
> you're really building with eVC 4. The same SOURCE CODE, maybe. You have
> to tell us what you are really doing, not some adjusted version that you
> think is the same, if you want help...
>
> If you *are* compiling with eVC 4, as you originally said, send the handle
> value, as it is returned from CreateThread ****IMMEDIATELY AFTER RETURN FROM
> CREATE THREAD**** to the debug port and ****IMMEDIATELY BEFORE CALLING
> WAITFORSINGLEOBJECT**** and verify that they are the same.
>
> Also, when you say, "I could see that the ExitThread(0) get executed", that
> makes me *very* nervous. What do you mean by that? You're single-stepping
> with the debugger? Or you put RETAILMSG() or OutputDebugString() calls
> before ExitThread() and those messages were printed?
>
> PLEASE BE VERY PRECISE ABOUT WHAT YOU'RE SAYING, AS WELL AS ACCURATE. If
> you don't do that, you're wasting both of our time...
>
> Paul T.
>
> "Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:298E17FA-37DD-4512-BE47-8E635E62F016@xxxxxxxxxxxxxxxx
> > Hi Tobey,
> >
> > Thanks for your insight. I tested the thread as you'd mentioned. I
> > could see that the ExitThread(0) get executed. But, the
> > WaitForSingleObject()
> > call never get the signal. Very strange??
> >
> > BTW, this same executable runs just fine in PPC 2002 platform. I am
> > using HP Jornada and Dell Axim X5 as PPC 2002s. For PPC 2003s, I am trying
> > HP
> > iPAQ hx 2000 and Dell Axim x50v. I do not know if this is platform
> > specific
> > or just a bug somewhere?
> >
> > Thanks,
> > -Channa.
> >
> >
> > "Paul G. Tobey [eMVP]" wrote:
> >
> >> I've done this many, many times and it *does* work, generally. I just
> >> took
> >> your code, added the bits that needed to be added to make it run (opening
> >> the port, closing the thread handle when you're done with it), ported it
> >> back to plain Win32 using global functions, and it works just fine. It
> >> might be helpful to put some debug messages in the thread so you can tell
> >> whether the thread is blocked at WaitCommEvent() or ReadFile() when you
> >> try
> >> to terminate it...
> >>
> >> Paul T.
> >>
> >> "Channa" <Channa@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:B5F8F028-AB9E-4270-B839-25A45E528DBD@xxxxxxxxxxxxxxxx
> >> > 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.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
.
- Follow-Ups:
- Re: PPC 2003 Thread
- From: Paul G. Tobey [eMVP]
- Re: PPC 2003 Thread
- References:
- PPC 2003 Thread
- From: Channa
- Re: PPC 2003 Thread
- From: Paul G. Tobey [eMVP]
- Re: PPC 2003 Thread
- From: Channa
- Re: PPC 2003 Thread
- From: Paul G. Tobey [eMVP]
- Re: PPC 2003 Thread
- From: Channa
- Re: PPC 2003 Thread
- From: Paul G. Tobey [eMVP]
- Re: PPC 2003 Thread
- From: Channa
- Re: PPC 2003 Thread
- From: Paul G. Tobey [eMVP]
- PPC 2003 Thread
- Prev by Date: Some general socket questions
- Next by Date: Re: Some general socket questions
- Previous by thread: Re: PPC 2003 Thread
- Next by thread: Re: PPC 2003 Thread
- Index(es):
Relevant Pages
|
