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

[Lex Trotman]

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

So we can't just blame the user :-(  we have to ensure that things
programmed into Geany can rarely cause damage.


>
>>> 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.
>

Ditto

Cheers
Lex

>
> Best regards.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>