Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: afb on November 09, 2006, 08:50:02 pm
-
Seems like in some cases on wxMac (like on PPC), wxExecute returns -1 for a child PID...
When you later pass this PID on to wxProcess::Kill, it is interpreted as "harakiri, please".
That is, it will kill all your process and programs and return to you to a fresh login start. :cry:
Investigating how you get to the real PID, or: "how the heck do I find GDB in that case...".
-
Heh, don't worry about wxExecute...
I've created a Win32 CreateProcess()/WaitForMultipleObjects() implementation, and Jonas Thedering was so nice as to contribute a fork()/select() version which should work on Linux and MacOS.
When I *finally* find the nerve to finish the environment handling (which I am delaying for weeks now because it sucks so bad), wxExecute will be history.
-
Wouldn't it be better to rewrite wxExecute (ie, keep the interface) then submit it upstream? That way the wxWidgets will eventually be responsible for it and it will get wider use and debugging.
-
Wouldn't it be better to rewrite wxExecute (ie, keep the interface) then submit it upstream? That way the wxWidgets will eventually be responsible for it and it will get wider use and debugging.
Oh that would be a great idea. I am currently suffering from wxExecute deficiencies and it could be helped with what you are proposing.
What do you think?
-
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).
-
Here is the related crashing bug:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=8950&group_id=5358
I'll just patch it to watch out for -1,
and look for your reimplementation.
-
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).
could you submit it as an alternative to wxExecute and let them decide if they want to adopt it? (I too would like a good alternative to wxExecute)
-
I guess I should of been more clear, with so many glaring deficiencies in wxExecute, why not propose a wxExecute v2. So what if the interface is different, if it accomplishes the same goal: spawning child processes and communicating with them asynchronously over stdin/stdout and in a more efficient and less buggy way it would at least be a good proposal. And if it does not get accepted upstream you could spin it off as a small side project. Then end goal is remove the CB devs from having to worry much about with esoteric things like process creation and let the wxWidgets people maintain it.
-
P.S.- All the talk you guys had about this, was this on the forum, in private messages, email, IRC? I just get the feeling that I missing out on part of the development process. I am just curious because the most of the insight we have on the dev cycle is from roadmap. And "wxExecute replacement" is definitely not on there. Also while I am at it Mac OS X support should be moved to the 1.0 release, because we are so close already.
-
I just get the feeling that I missing out on part of the development process.
you're not alone in that feeling, I feel that we're somewhere in between the cathedral and the bazaar...;
I fully agree with message http://forums.codeblocks.org/index.php?topic=4435.msg35088#msg35088
if the implementation/interface is universal enough there are chances it will be accepted in upstream wx
-
if the implementation/interface is universal enough there are chances it will be accepted in upstream wx
Universal, as in hardcoding the maximum number of commandline arguments to 127 and writing into a non-allocated memory region for any larger number? :)
-
Thomas, probably it is time to post the code, wxExecute's interface and implementation is nightmare and we continue to suffer by it.