2009/8/17 Thomas Martitz <thomas.mart...@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 :-)
