[Geany-devel] ANN: Configurable Build Menu Alpha in SVN

[Thomas Martitz]

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.