Re: PPC 2003 Thread

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.
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>


.

Relevant Pages

  • Re: Display Rendering Problem
    ... perhaps adding debug messages to lots of places in the code to try to figure ... drivers except display driver. ... Paul G. Tobey wrote: ... the UI response delay can be visualized at ...
    (microsoft.public.windowsce.embedded)
  • Re: How to Access Window Messages
    ... Paul G. Tobey [eMVP] ha scritto: ... I also test the IntPtr values and here you the results: ...
    (microsoft.public.windowsce.app.development)
  • Re: Adding both .NET 2.0 and 3.5
    ... PB just can't deploy both to the same image and as Paul pointed out, there's no reason to ship both on a device anyway. ... Platform manager allows all versions to be added ... If you need to run .NET CF 3.5 applications, then add .NET CF 3.5 and live with it. ... It looks like that if I have only .NET 3.5 then I am able to execute both 2.0 and 3.5 programs in debug mode using VS2008. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: NETCF2 included but not built
    ... bought Platform Builder and call Microsoft. ... Paul G. Tobey wrote: ... the Platform builder 4.2 has .net compact framework 2.0 ... unpacked from the installation of that works fine in the target ...
    (microsoft.public.windowsce.embedded)
  • Re: NETCF2 included but not built
    ... bought Platform Builder and call Microsoft. ... Paul G. Tobey wrote: ... the Platform builder 4.2 has .net compact framework 2.0 ... unpacked from the installation of that works fine in the target ...
    (microsoft.public.windowsce.embedded)