Re: serial reader ui-thread solution?
On Jan 7, 10:26 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On Fri, 7 Jan 2011 11:25:06 -0800 (PST), Goran <goran.pu...@gmail.com> wr=
ote:
On Jan 7, 5:32 pm, mfc <mfcp...@googlemail.com> wrote:
Hi,
is it also possible to use an ui-thread for the serial reader-method?
I`ve two threads which "can" receive the receive message from the
serial reader-thread; but only one of these two threads will receive
the message from the serial-reader-thread. The user is able to switch
between these two threads.
Using a normal workerthread (for the serial reader thread), I always
have to close the thread (serial-reader) and re-create it, if the user
switch between the two threads receiving the message fromt he serial
reader.
Using a ui thread I can post message to the serial reader thread, that
the user wants that threadA will receive the pkts or threadB.
while(running)
{ /* read loop */
BYTE buffer[MAX_RXD_BUFFER_SIZE];
BOOL ok = ::ReadFile(parms->hCom, buffer, MAX_RXD_BUFFER_SIZE - 1,
&bytesRead, &ovl);
if(!ok)
{ /* error */
DWORD err = ::GetLastError();
if(err != ERROR_IO_PENDING)
{ /* read error */
shutdown = err;
::PostThreadMessage(parms->artnetTh, UWM_READER_SHUTTING_DOWN,
(WPARAM)parms->channelID, (LPARAM)err);
running = FALSE;
continue;
} /* read error */
// otherwise, it is ERROR_IO_PENDING
DWORD result = ::WaitForMultipleObjects(2, waiters, FALSE, INFINITE)=
;
switch(result)
{ /* wait */
case WAIT_OBJECT_0: // shutdown
::CancelIo(parms->hCom);
shutdown = ERROR_SUCCESS; // clean shutdown
running = FALSE;
continue;
case WAIT_OBJECT_0 + 1: // I/O complete
ok = ::GetOverlappedResult(parms->hCom, &ovl, &bytesRead, TRUE);
if(!ok)
{ /* GetOverlappedResult failed */
DWORD err = ::GetLastError();
::PostThreadMessage(parms->artnetTh, UWM_READER_SHUTTING_DOWN,
(WPARAM)parms->channelID, (LPARAM)err);
running = FALSE;
continue;} /* GetOverlappedResult failed */
break;
default:
{ /* trouble */
shutdown = ::GetLastError();
running = FALSE;
} /* trouble */
} /* wait */
}
//write this received data msg to threadA or threadB (determining of
threadID)
::PostThreadMessage(threadID, UWM_READER_SENDING_DATA,(WPARAM)pData,
0);
if the thread waits in the (DWORD result = ::WaitForMultipleObjects(=
2,
waiters, FALSE, INFINITE)) the whole thread is blocked so that I can
not send any postmessages to this thread - or better the thread didn`t
process these messages.
How is it possible to write this function in an ui-thread, so that the
ui thread is always able to get / process any postmessages?
I am not sure what you are doing, but... Are you talking about one and
only thread here? If so, and if your thread is NOT your main UI
thread, you might do it using MsgWaitForMultipleObjects. Replace
WaitForMultipleObjects with MsgWaitForMultipleObjects.
MsgWaitForMultipleObjects returns when there are messages to process
with WAIT_OBJECT_0 + 2 (well, 2 in your case), so your thread can both
wait for IO completion and process messages if they arrive.
****
The problem here is that by bypassing the standard message queue handling=
, you are getting
into trouble.
Yes. That's why I said "if your thread is NOT your main UI thread". I
thought that by "UI thread", original poster meant "any thread that
runs message queue". I don't think that I am the only one that,
probably wrongly, but there you have it) also calls such threads "UI
threads". I believe that there's no reason for a program to run more
than one thread who actually interact with the user, so it came out
the way it did.
Where, for example, do you handle the OnIdle processing, and in particula=
r,
the default OnIdle processing that cleans up temporary objects? This i=
s a risky form of
handling messages, and it is a completely an artifact of trying to force =
a square peg into
a round hole. You have suggested a way of lopping corners off the peg,=
but it changes the
very nature of the peg. So the real problem is that this is not a very=
good idea in the
first place, and I see no reason to add gratuitous complexity that may no=
t work right in
all cases, when putting this into a pure worker thread avoids the problem=
entirely.
Yes, of course, MsgWaitForMultipleObjects(Ex) work in limited
circumstances. A thread that runs it's own message loop (e.g. for
purpose of being told what to do through PostThreadMessage), and wants
to wait on some handles, WFMO style, is one, I believe.
Goran.