Re: worker thread
On 5 Nov., 21:10, mfc <mfcp...@googlemail.com> wrote:
According to your code, everyting is working...
// reset an old dead thread
if (m_pWorkerThread != NULL)
{
DWORD dwExitCode;
GetExitCodeThread(m_pWorkerThread->m_hThr=
ead, &dwExitCode);
if (dwExitCode == STILL_ACTIVE)
return FALSE; //worker th=
read already exists and is alive -> do not
start it again
else
m_pWorkerThread = NULL;
}
The verification can be started by the dialog as well as by the
webserver. Therefore I`m searching for a solution, where this function
won`t return FALSE if the worker thread is already running. All
incoming verification requests should be proceed step by step, so that
always one worker thread is running at the same time.
WaitforSingleObject isn`t a good solution, because the mainthread (in
this case) will be blocked until the next worker thread could be
started.
Is the only appropriate solution to add all requests in a queue?
Well, here I don't know your app well enough.
For your previous posting: Yes I could imagine that you do all
the stuff related to your verification process in the worker thread.
The only things which are difficult in a worker thread are those
related to some window. Remember, a worker thread has no message
pump. And all MFC windows classes can't be used in a worker thread.
Ignoring this will bring you in deep trouble. (However, OTOH
API level functions related to some window do work even from the
worker thread. But be careful.) So, in general, if after a successful
verification you want to, say, update you dialog window, you should
not try to do it directly from the worker thread, but instead post
some message to the window, so that the main thread can to the update.
BTW you also could use SendMessage instead of PostMessage, but that
can bring you in a deadlock situation. Some time ago I wanted to
update a progress bar from a worker thread by PostMessage. I noted
that depending on the OS (Win9x vs. NT based) some of the messages
did not seem to be handled. In fact they were put into the message
queue,
but the main thread handled all those messages at once.
Therefore I considered SendMessageTimeout, so that the messages were
handled immediatly, but avoiding the possible deadlock. Only if
SendMessageTimeout returned with timeout, I added another PostMessage
(at least for important messages). That made the progress bar behave
smoothly again.
About your current posting: It seems that your application has to
handle several requests. If I understand it correctly, they must be
handled one after the other, avoiding parallel handling. You also
might consider one separat worker thread for each request.
But then you also would have to queue them an synchronize them, maybe
in a manner the only the oldest worker thread is allowed to do it's
work while all the others wait. After the oldest one has finished
(i.e. just before it's prodedure returns) it must allow it's
successor to start working. However note that the number of
worker threads is limited.
Or you have only one worker thread handling the queue of incoming
requests.