[wx-dev] wxProcess maze

[Vadim Zeitlin]

On Mon, 30 Apr 2007 21:34:44 -0400 Wade Brainerd <wadetb at gmail.com> wrote:

WB> First, my issues with creating and managing the process:
WB> 
WB> So, wxExecute lets you pass in a object that is pre-configured for
WB> redirection, and also can accept an event handler to receive termination
WB> notices.  Unfortunately, wxExecute doesn't set wxProcess's PID member,
WB> instead it returns the PID. wxProcess::SetPID is a protected function, so
WB> you can't call it after calling wxExecute.  You need the PID in order to
WB> kill the process later, unless you store it in your own variable.

 Well, this doesn't seem such a big deal especially as usually whenever you
launch multiple processes you have a map PID -> wxProcess* anyhow. But I
agree that wxExecute() could set the PID on the process pointer passed to
it.

WB> Alternately, you can use wxProcess::Open which sets PID properly (by calling
WB> SetPID after wxExecute), but that doesn't let you specify an event handler
WB> to receive termination notice before the wxProcess object is destroyed.

 Again, I agree that it would be useful to be able to pass wxEventHandler
pointer to wxProcess::Open().

WB> For example, wxExecute could allow you to pass in your own streams.

 This risks to be difficult to implement.

WB> Or if a process object is passed in, wxExecute should definitely set
WB> its PID.

 Yes. If you could please make a patch doing this, I'd be glad to apply it.

WB> wxProcess::Open could optionally take a callback wxProcess*, and simply
WB> return it. 

 It doesn't make sense for a static class method to take a class instance
as parameter. Why not just have a non-static Open() instead (or Run() if
you prefer)?

WB> I would also probably change the notion of redirection (Redirect(),
WB> also the flag) to be a "process creation time" flag rather than a
WB> property of the wxProcess object.

 You can already specify it at the process creation time using
wxPROCESS_REDIRECT flag in the ctor.

WB> Also, I would change the lifetime of wxProcess objects to be more
WB> handle-like, so that when the object is destroyed it simply has a
WB> non-static Exists() method which returns false.  This would eliminate
WB> the need to derive from wxProcess in order to not have the object
WB> deleted from under you.

 And would also probably result in a lot of memory leaks because when will
the process be destroyed then? And, anyhow, normally you must always react
to the process termination.


WB> My second problem is actually reading the streams:
WB> 
WB> I would like to interleave the stdout and stderr line by line, as they are
WB> flushed by the console application.  I haven't been able to find a way to do
WB> this, so I'm currently polling them in the Idle event and with a wxTimer.
WB> This is fine for occasional output, but breaks down under high output.

 This is about the same thing as the exec sample does. I'm not sure what
exactly do you mean by "breaks down" though. Of course, it's not the most
efficient way of doing things but short of integrating these streams in the
main event loop (but then maybe Lukasz has plans to do it...) I don't see
what else can you do without using threads.

WB> As far as I know, the only way to do this is to create a thread for each
WB> stream, which blocks on a call to ReadFile and raises an event or makes a
WB> callback each time ReadFile returns.  I'm not sure if this can be done in
WB> the wxWidgets API, or if I would have to drop down to Win32.

 I don't understand why should it be so complication. The thread should
just block and whenever it reads something post an event to the main
thread.

WB> Would it be possible to add OnInputReceived and OnErrorReceived callbacks
WB> for wxProcess, and/or events to be passed to the event handler?

 Maybe it is but I don't really see how. It would be definitely useful if
we could do this though.

 Regards,
VZ