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

[Thomas Martitz]

Lex Trotman schrieb:
> 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 :-)
>   

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.