The interface is almost completely done, and it is definitely not the
wxExecute one, this would mean an almost complete rewrite (and a painful one).
I am not even sure whether the implementation is compatible with the way
wxExecute is supposed to work from their point of view (they do all kinds of strange things like wxYield(), which we don't), and honestly I care very little, too. The assignment was not to rewrite
wxExecute. The assignment was/is to provide something that does the job for us. There are quite a few things that
wxExecute has no provisions for, but which would be valuable for our application.
The original reason why we started this was that Jonas in particular was annoyed by the abysmal performance under Linux which mostly comes from spawning one dedicated watcher thread per process launched, running in a semi-tight spinloop and doing all kinds of strange stuff.
When he complained about it, I replied "yeah, I know... it sucks dick, but what can we do, it's the way it is. This should be done somehow like one single watcher thread, and
select blocking on the pipes. I've done that for Windows before, but I don't have the time to write such an implementation for every platform".
Thus quoth Jonas: "No problem, I shall provide the POSIX version". And indeed, he had it ready two days later...
Then we discussed a bit about it and found that while we are at it, we should fix a few other shortcomings, too. For example, handling pathnames with spaces is always awkward, the data coming via
stdin is copied around at least 5-6 times and always pushed through the message queue, the handling is not 100% nice for every application, and you have no way whatsoever to specify an environment for a child process (you can
setenv() before spawning a process, but that's not the same, and it is faulty and clumsy, too).
