Worker threads and wxExecute
Bill Nalen
I believe there are some serious issues with calling wxExecute from a
thread (at least on MSW 2.4.0). My situation is this:
MyApp
OnInit
create frame for all GUI stuff
create worker thread and Run() it
Inside worker thread
call wxExecute(...) (sync in my case with capture of output & errors)
What happens is this:
wxExecute creates hidden frame to collect messages while the process is
running.
Inside the loop waiting for messages on the frame, Sleep and Yield are
called.
The Yield function seems to assume it is being called from the main
thread and may do a wxMutexGuiLeaveOrEnter and may also do a
wxTheApp->DoMessage(). Both of these give errors if not called from within
the main thread. Checking Yield or parts thereof to make sure they are
running in the main thread won't work since messages won't be processed
otherwise.
There's also a couple of error messages spit out about DestroyWindow
failing, but I think these are related to the temp window created/destroyed
and not really a problem.
I've looked at the mailing list archive and it seems others have seen this
problem too (in fact the thread sample program will exhibit this behaviour
if you change the command run to something that takes a little bit of time
to complete). I've looked at CVS too, and none of the check ins seem to
deal with this.
Any thoughts on this? One thing I'd like to try is replacing the wxFrame
created and wait loop with a call to WaitForSingleObject. I'm not sure
what else would need to be fixed up but I think this win32 function will
allow other threads to keep running and processing messages while it's
waiting for the CreateProcess to finish.
Thanks
Bill
Bill Nalen
VZ wrote:
> Yes, this doesn't work. Under MSW it could be made to work but the
problem
>is that under Unix (with pthreads) there is apparently no chance of making
>it to work right so I didn't waste time on fixing MSW. You should be able
>to find extensive discussions of this problem in the archives.
Could we get the docs updated to say that you can never call wxExecute from
a non-main thread? I spent about 10-20 hours trying to track this down. I
only found a few mentions of threads in the archives.
Also, perhaps the docs for wxYield should say that you can't call it from a
non-main thread and to use wxThread::Yield() instead.
Thanks
Bill
Dimitri
>VZ wrote:
> > Yes, this doesn't work. Under MSW it could be made to work but the
>problem
> >is that under Unix (with pthreads) there is apparently no chance of making
> >it to work right so I didn't waste time on fixing MSW. You should be able
> >to find extensive discussions of this problem in the archives.
>
>Could we get the docs updated to say that you can never call wxExecute from
>a non-main thread? I spent about 10-20 hours trying to track this down. I
>only found a few mentions of threads in the archives.
Besides the docs, an assert in wxExecute checking if we're in the main
thread would be very welcome. Could somebody add it please? (If not I'll
submit the trivial patch)
Regards,
Dimitri
Vadim Zeitlin
D> At 08:32 PM 2/25/2003, you wrote:
D>
D> >VZ wrote:
D> > > Yes, this doesn't work. Under MSW it could be made to work but the
D> >problem
D> > >is that under Unix (with pthreads) there is apparently no chance of making
D> > >it to work right so I didn't waste time on fixing MSW. You should be able
D> > >to find extensive discussions of this problem in the archives.
D> >
D> >Could we get the docs updated to say that you can never call wxExecute from
D> >a non-main thread? I spent about 10-20 hours trying to track this down. I
D> >only found a few mentions of threads in the archives.
D>
D> Besides the docs, an assert in wxExecute checking if we're in the main
D> thread would be very welcome. Could somebody add it please? (If not I'll
D> submit the trivial patch)
I've just done it.
Now let's wait for someone submitting a patch to make this really work :-)
Regards,
VZ