Lex Trotman schrieb:
2009/8/17 Thomas Martitz thomas.martitz@student.htw-berlin.de:
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.
Same thing ;-)
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.
Oh, interesting, I don't know why it doesn't work, unless the signals are blocked somewhere?? Does your execute kill things correctly??
SIGQUIT is used by execute when it changes to stop, although it isn't the friendliest signal, see comment in build.c.
It probably should be SIGTERM which is the canonical "die now" signal, but then Geany's SIGTERM callback would have to decide where the signal came from and thats a-priori impossible.
Although, I am not sure why Geany should get the signal sent to its child?? The comments in build.c say it does but I don't know why. It doesn't happen in normal circumstances when a signal is sent to a child.
Can anyone else throw any light on why???
Something to examine further, the process creation and killing code in build-system is basically unchanged from 0.17 Geany.
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*.
No they are not in the same process group as the shell, do ps -o pid,ppid,pgid,command Or rather if bash has job control enabled they aren't, but I assumed it would be available for any recent Linux.
Things terminate when you terminate a shell because it sends SIGHUP to all its process groups at exit or they get tty control signals when their controlling terminal is disconnected. Shell also behaves differently if its interactive and if its a script.
Oh, and much of this behaviour is configurable too :-S
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.
Well *thats* a very much bigger job than just one call to kill :-) and the comment below is still valid.
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.
And getting the process list is easier in a script, just run ps (or ptree if your system has it) and grab the output
But for C there isn't a system call to do it. AFAIK ps and top use an undocumented libproc, all others read the /proc directory tree, which is a pain. Or you could run ps in a subprocess & get its output. As I said a lot more work than just calling kill.
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.
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
For those we can make sure it doesn't harm to kill those. Otherwise I consider this as an actual bug in Geany.
So we can't just blame the user :-( we have to ensure that things programmed into Geany can rarely cause damage.
We can. Running an external script has nothing to do with "programmed into Geany", it just starts it (it even lets a shell start it).
That's like not implementing system calls in a operating system. Just because one can write harmful software using system calls?
Best regards.