Lex Trotman schrieb:
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Ok, which is client and which is server is not well defined :-)
It is, it just wasn't obvious in the snippet.
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
Well, yes it is, thats too drastic, you don't know what else is running. If you use something like this elsewhere you just set the handler to SIG_IGN, thats what its for.
:D I set it to SIG_IGN for the main program. And set it back to what main.c sets it to afterwards.
As an aside don't try blocking the signal, Geany (actually GTK+) uses multiple threads and you will only be blocking the main thread. So I guess thats advice for all GTK programs.
I don't think I'm blocking the main or any thread or signal.
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
But it only kills the parent build process, unfortunately all the issues about children still apply.
It doesn't do *anything* here. I also tried SIGQUIT (since a comment in main.c says "/* SIGQUIT is used to kill spawned children and we get also this signal, so ignore */") with the same effect.
Remember your ctrl-c from the terminal doesn't kill background processes because they are in another process group.
When I cancel make -j5 with CTRL+C, all of make's forks are terminated too. What do you mean with background processes, does that apply here? If you mean those process started with a '&' at the end, those are also in the same process group as the shell (they die if you terminate the shell)...*IIUC*.
Your make script might not run other processes, but there is nothing preventing a script from running background processes or anything. We do *not* know what the users build executes and what a mess it might leave if terminated.
Thats why I say it should not be programmed into Geany, it makes too many assumptions.
I don't see what's wrong with "kill child and its childs [and so on]" upon canceling. IMO, the user is in the duty to not create damaged build commands that break the system if they're cancelled (which is a manual action after all, i.e. the user doesn't need to hit it if he knows his script is going insane).
Killing/terminating *all* processes that are started due to the initial build command is a very valid action IMO.
As I said before, if it works for you in a particular situation configure it as a command, but just because it works for you does *not* mean it is safe in general. Having a command which is a script (even a perl one ;-) examine the process tree and find the "make" children of the instance of Geany that is a parent of the script itself (you may have to read that slowly, I did to ensure I got it right) would be the best way to go to avoid clobbering any other makes that are running and anything running from any other instances of Geany.
I might just do that, now that I know of the hidden additional run commands.
But programming one way of killing a build into Geany that may not work or may do damage is a bad idea.
As I said, the user is on fault if his commands cause damage. There are a lot of possibilities that the command dies without geany doing anything, and that's the users problem too then.
The geany.html is currently broken here due to svn merge (which took surprisingly long, some 30min) :D But I did not know that, thanks!
Was that merging trunk with your working copy? I will be merging trunk into build-system soon as 0.18 is released so let me know of any big problems. geany.html doesn't matter because it can be re-generated but if there are other problems its would be good to be warned. Build.c always has to be manually merged though.
Yea, it worked fine, just two uninteresting files conflicted. But of course I'm looking forward for this thing being in the trunk.
Best regards.