Console app and wxThread::Wait

[Armel Asselin]

Hello,

(wxMSW2.6.2)
I'm trying to make a __console__ application which launches several threads
and then wait for these threads to terminate.
The problem is that it actually never ends and takes 100% CPU... looping on
a WaitForMultipleObjects which returns immediately
WAIT_OBJECT_0 + 1, then the code does a ::PostMessage( ) and then calls
DoMessageFromThreadWait ( ) which does absolutely nothing, then it loops
again and again.

I've made a small array of wxThreadHelpers.
At start I do that for each thread helper:

if (thread->GetThread() == NULL)
{
thread->Create( );
thread->GetThread()->Run( );
}

When i'm finished with adding tasks, and simply want to wait for the threads
end i do this:

for (size_t i=0; i<threads.nb_elem(); ++i) {
if (threads[i].GetThread() != NULL) {
threads[i].GetThread()->Wait();
}
}

is it the right thing to do? all the threads exit simply at the end of the
Entry( ) function normally, returning a code (which I see well in the IDE
debugger when the threads end)
any other idea?

Regards
Armel

[Armel Asselin]

putting a:

MSG msg;
while (!::PeekMessage(&msg, 0,0,0, TRUE));

in DoMessageFromThreadWait ( ) solves my problem... is it a good idea to do
that??

please tell
Armel

"Armel Asselin" <armela...@hotmail.com> a écrit dans le message de news:
43f7481a$0$20183$8fcf...@news.wanadoo.fr...

[Vadim Zeitlin]

On Sat, 18 Feb 2006 17:15:19 +0100 Armel Asselin <armela...@hotmail.com> wrote:

AA> I'm trying to make a __console__ application which launches several
AA> threads and then wait for these threads to terminate. The problem is
AA> that it actually never ends and takes 100% CPU... looping on a
AA> WaitForMultipleObjects which returns immediately WAIT_OBJECT_0 + 1,

I don't understand why does this happen but we probably shouldn't use
MsgWaitForMultipleObjects() for console applications anyhow and use a
simple WaitForSingleObject() in console applications. Of course, we'd have
to extract it into a traits class to allow for this but this seems logical:
console and GUI applications don't wait in the same manner. And
virtualizing the wait operation seems good for other reasons too because
the user code might want to implement it differently if it has any other
event sources for example.

AA> putting a:
AA>
AA> MSG msg;
AA> while (!::PeekMessage(&msg, 0,0,0, TRUE));
AA>
AA> in DoMessageFromThreadWait ( ) solves my problem... is it a good idea to do
AA> that??

I don't think so. I really don't understand why should console application
handle any messages at all.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
For additional commands, e-mail: wx-use...@lists.wxwidgets.org