> Because (a) that wouldn't prevent the CPU hogging, and (b) because
> users never obey what they're told and will always try and click
> something anyway
> {:v) I would feel that this makes the app non-robust since it relies
> on the user playing nice, and if they don't, the app provides
> incorrect information since it gets its comms mixed up (been there,
> done that in early iterations - the result was not good).
I didn't mean just being polite and *asking* them not to do so, that won'r
work for 99.999999% percent of the users! :-) I meant checking in your
button click handler code if anything's going on in the background, and if so,
show that red sign, and *abort* user's request.
> Structure {:v) Cue the arguments about what the prefix should be {;v)
I'd probably not bother to give a prefix to the whole thing. I'd probably
call the variable "ov", but that wouldn't fix your problem, would it?!
> Yes for the first...
>
> m_hPortHandle = ::CreateFile(lpszPortName, GENERIC_READ|GENERIC_WRITE,
> 0, NULL, OPEN_EXISTING,
>
> FILE_FLAG_OVERLAPPED, NULL);
> (that handle gets set into the rsThreadData member accordingly)
This is fine.
> but no for the second... can you explain why I should have manual
> reset? I think this was one I didn't know what I should do, so I chose
> automatic.
Well, the big reason is that MSDN says so, and that is because maybe it's
supposed to allow multiple threads to wait on the event. But I noticed in
their sample code they're creating an auto-reset event, so it's yours to
decipher this MSDN inconsistency, although I'd presonally create the event
manual-reset, and call ResetEvent( ) myself when I get the notification.
> // Wait for completion of WaitCommEvent().
> while (!rsThreadData.bTerminate && !bDone)
> {
> bDone = ::GetOverlappedResult(rsThreadData.hPortHandle,
>
> &rsNotifyOverlapData,
>
> &dwDummy, FALSE);
> dwError = ::GetLastError();
> if (!bDone && dwError != ERROR_IO_INCOMPLETE)
> bDone = TRUE ; // Real error.
> }
>
> Thoughts? Told you this was my first foray into the seedy world of
> handles, events and threads {;v)
For the first foray, it's pretty good! :-)
Now, like I suspected in my last email, there is *nothing* that causes a real
"wait" in the loop, and that's the reason of CPU hogging. I guess now you see
this.
> I think it may, if you have any more thoughts about that inner loop in
> WaitForRX() - Daniel suggested I should simply wait for the handle in
> the OVERLAPPED structure to become signalled, I guess you would
> concur?
Yeah, definitely. You should call GetOverlappedResult( ) after your wait
function returns successfully, and pass FALSE as its last argument.
BTW, in case it's not obvious, this is the overlapped I/O model in Windows.
You can use it in any I/O (like file I/O, socket I/O, port I/O, etc.) and it
always works like this. For example, to read a large file, you could issue 10
I/O requests, and then call WaitForMultipleObjects( ) to automatically be
alerted of which one finishes first, and then issue more requests if needed.
-------------
Ehsan Akhgari
Farda Technology (http://www.farda-tech.com/)
List Owner: [email protected]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
It is dreadful to die of thirst in the sea. Do you have to salt your truth so
much that it can no longer even - quench thirst?
-Beyond Good And Evil, F. W. Nietzsche
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
