Running Console App on Secondary thread

[Stefano Mtangoo]

Hi,
I have a thread (secondary) that needs to launch console app and catch
errors an post them back to Main thread.
wxExecute does the task well but then It cannot be run on Secondary thread.
Is there any other (even a Linux/Window) solution
I can use for that? App takes long time and so will freeze the GUI.
Thanks,

Stefano

[Vadim Zeitlin]

On Sat, 1 Mar 2014 10:38:52 -0800 (PST) Stefano Mtangoo wrote:

SM> I have a thread (secondary) that needs to launch console app and catch
SM> errors an post them back to Main thread.

The best I can suggest right now is to use POSIX popen(), which is also
available as _popen() with MSVC under Windows. It would be, of course, nice
if wxExecute() could be made to work from non-GUI threads too and perhaps
it would be simpler now, after the recent changes to its implementation...

Regards,
VZ

[Stefano Mtangoo]

Post by Vadim Zeitlin
SM> I have a thread (secondary) that needs to launch console app and catch
SM> errors an post them back to Main thread.
The best I can suggest right now is to use POSIX popen(),

Thanks Vadim,
I will have a look at it.

Post by Vadim Zeitlin
which is also
available as _popen() with MSVC under Windows.

Is it also available under MinGW? I have always avoided MSVC in favor of
cross-development
with GCC.

Post by Vadim Zeitlin
It would be, of course, nice
if wxExecute() could be made to work from non-GUI threads too and perhaps
it would be simpler now, after the recent changes to its implementation...

How is it going to be added? New Overloaded method? New flag?
Regards,
S.

Post by Vadim Zeitlin
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Vadim Zeitlin]

On Mon, 3 Mar 2014 02:54:09 -0800 (PST) Stefano Mtangoo wrote:

SM> > which is also
SM> > available as _popen() with MSVC under Windows.
SM>
SM> Is it also available under MinGW? I have always avoided MSVC in favor of
SM> cross-development with GCC.

It should be but it's really better to simply test.

SM> > It would be, of course, nice
SM> > if wxExecute() could be made to work from non-GUI threads too and perhaps
SM> > it would be simpler now, after the recent changes to its implementation...
SM> >
SM> How is it going to be added? New Overloaded method? New flag?

Ideal would be to just make it work without any new flags. If this is
(still) impossible, we could interpret wxEXEC_BLOCK as meaning "use popen()
in secondary thread".

Regards,
VZ

[Stefano Mtangoo]

Post by Vadim Zeitlin
SM> > which is also
SM> > available as _popen() with MSVC under Windows.
SM>
SM> Is it also available under MinGW? I have always avoided MSVC in favor of
SM> cross-development with GCC.
It should be but it's really better to simply test.

Will test it today!

Post by Vadim Zeitlin
SM> > It would be, of course, nice
SM> > if wxExecute() could be made to work from non-GUI threads too and perhaps
SM> > it would be simpler now, after the recent changes to its
implementation...
SM> >
SM> How is it going to be added? New Overloaded method? New flag?
Ideal would be to just make it work without any new flags. If this is
(still) impossible, we could interpret wxEXEC_BLOCK as meaning "use popen()
in secondary thread".

This latter is better. After testing popen/_popen I will make a patch!

Post by Vadim Zeitlin
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Stefano Mtangoo]

Post by Stefano Mtangoo

Post by Vadim Zeitlin
SM> > which is also
SM> > available as _popen() with MSVC under Windows.
SM>
SM> Is it also available under MinGW? I have always avoided MSVC in favor of
SM> cross-development with GCC.
It should be but it's really better to simply test.

Will test it today!

Post by Vadim Zeitlin
SM> > It would be, of course, nice
SM> > if wxExecute() could be made to work from non-GUI threads too and perhaps
SM> > it would be simpler now, after the recent changes to its implementation...
SM> >
SM> How is it going to be added? New Overloaded method? New flag?
Ideal would be to just make it work without any new flags. If this is
(still) impossible, we could interpret wxEXEC_BLOCK as meaning "use popen()
in secondary thread".

This latter is better. After testing popen/_popen I will make a patch!

Just to report that popen works quiet well.
I will test the Windows version before I do make the patch

Post by Stefano Mtangoo

Post by Vadim Zeitlin
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Marian 'VooDooMan' Meravy]

Greetings,

first of all, sorry for late response.

Post by Stefano Mtangoo
Hi,
I have a thread (secondary) that needs to launch console app and catch
errors an post them back to Main thread.
wxExecute does the task well but then It cannot be run on Secondary thread.
Is there any other (even a Linux/Window) solution
I can use for that? App takes long time and so will freeze the GUI.
Thanks,

I had exactly the same problem, i.e. console app took very long time
(say 3 minutes).

In secondary thread I push my special structure with command line,
semaphore signalling when console process is done, environment variables
for it, stdin that will be injected to sub-process, etc.., I push it to
STL vector guarded by critical section.

Main thread (GUI event loop) in OnIdle is reading that vector and spawns
process in ASYNC mode (i.e. it will not block), and from time to time
reads its stdout and feeding by results in chunks to that structure from
vector and signals semaphore that there are some data to read for
secondary thread.

When process finishes, it signals (done-)semaphore, and secondary thread
can finish reading its data, if there are any left.

This solution is portable, since it is pure-wxWidgets (except for STL
vector, however, you can still use wxVector/wxList), and you don't need
to worry about (possibly) non-portable popen().

best,
vdm
.