[Geany-devel] ANN: Configurable Build Menu Alpha in SVN
thomas.martitz at xxxxx
Sun Aug 16 16:06:31 UTC 2009
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
> 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.
More information about the Devel