WxProcess
From WxWiki
Contents |
[edit] wxProcess
See also: WxExecute
[edit] Gotchas
[edit] SIGTERM signal on wxMSW only works on windowed applications
As of wx2.3.3, if you call wxKill() function or the equivalent wxProcess::Kill() function on MSW with a wxSIGTERM function, it will only do anything if the process you are trying to kill has a window. If it is a commandline-only, then you need to kill it with wxSIGKILL for it to have any effect at all. This still holds in 2.6.0, however, wxSIGNONE appears to function.
[edit] Never-ending input streams during piped input
If you are looking at adapting the /samples/exec to your project, you will see that it catches both stderr and stdout streams from the process. For your own application, if you want the dialog to refresh every so often while the redirected output is displayed, only use the stream that you expect to be generating some output. Otherwise the Eof() of the stream with no input will cause a holdup until the process is terminated, and you won't get a refresh until the end.
[edit] BCC asserts on wxProcess::Exists()
wxProcess::Exists(int pid) asserts on Borland C++ 5.5. But shouldn't be using this in a dialog anyways, since you should be keeping track of whether your own process is still running. Otherwise another program could start a process with that id and thus the process id would end up existing and it would be killed.
[edit] Thread issues
wxProcess/wxExecute are NOT thread safe. In wx2.6.0, the unix/msw ports (others unknown?) will still only allow wxExecute from the main thread (see src/msw/utilsexc.cpp:540 (rcs rev 1.79) and src/unix/utilsunx:251 (rcs rev 1.123)). This is only when WXDEBUG has been set. *DO NOT* ignore this or comment it out: under Unix (GNU/Linux2.4 specifically but this is probably mostly the case) a fork (wxExecute is, as expected, a well-protected invocation of fork/exec) will inherit the entire memory space of the parent, including locking bodies (mutexes etc). Forking and attempting to manipulate thread operations of the parent process will result in unknown behaviour - at best a segmentation fault (this could be nontrivially solved with clever use of pthread_atfork). This is also reported to be a "problem" in earlier versions of wx (2.4.x).
[edit] Console issues
Unix ports (wx2.6.0) will allow asynchronous (wxEXEC_ASYNC) wxExecute functions to fork but will fail with an ASSERT while (or rather, before) waiting for the child pid leaving the child active while the parent traps. This only occurs in console mode WXDEBUG when wxApp has not been properly invoked. See src/unix/baseunix.cpp:73 (rcs rev 1.12).
