Lex Trotman schrieb:
2009/8/16 Thomas Martitz <thomas.mart...@student.htw-berlin.de>:
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by
accident or when you realise you forgot to do something first. I've
done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs
in a terminal (either external or VTE) but build commands are run
directly so that no terminal window pops up and so that the output can
be captured for parsing for errors.
Due to problems on windows, builds have to be run synchronously on
windows, ie the whole of Geany freezes while the build runs (why? I
don't understand exactly, maybe Enrico can explain it).
That means that cancelling a windows build can't be done from Geany
anyway.
Whilst Linux builds are still asynchronous only one is allowed at a
time so that output isn't mixed up in the error parser. So all build
commands are set insensitive until completion. To have one menu item
still enabled and to have it change to stop is going to be quite a bit
of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel
button which doesn't gray out is going to be doable without a lot of
fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any
children that make forked to process subdirectories, or because -j was
used, and they won't get killed (they migrate to be children of init).
The overall impact is not well defined, but killing a top level make
may leave most of the build still running. Now setting the build
menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those
which are started with -jX) using this snippet of perl code. Note that kill
here is a perl function, which does IIUC killing the childs for us (it kills
the process groups if the signal parameter is negative). I don't know if it
helps us though.
Could one try call the perl function from within geany with a crude
hack/magic?
Um no, that would require Geany to have a dependency on Perl, and I
doubt that such a requirement would be acceptable to the general Geany
community.
I havn't written perl for a while but this seems to depend on the
global builds variable, whats that got in it and where was it set??
sub killchild
{
my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe};
$read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid};
kill -9, $pid;
tprint "Killed build $id\n";
waitpid $pid, 0;
my $dir = "$cwd/build-$pid";
if (-d $dir) {
tprint "Removing $dir\n";
rmtree $dir;
}
delete $builds{$id};
}
I actually got interested in adding the configurability to Geany build
system when an organisation I was consulting to was using Geany but
running builds on a server farm with several versions of Linux, AIX,
HP-UX, Solaris and several windows versions. And different pieces of
software from many different sources used many different build
systems, hence the need for configurability.
Of course such remote jobs won't be touched by any signals.
According to the reference you provided on Rockbox it does remote
builds by copying data from SVN and then copying the results back. So
a remote build can be cancelled by its special server on the remote
system (I guess thats where the perl snippet came from) and thrown
away and no corruption is possible, but our system used shared sources
for all machines and locks to control multiple build interactions.
Killing things could leave locks about and block builds until someone
removed them manually.
Worse some pieces of software could corrupt the build tree if
cancelled (sure they were lousy build scripts, but we used software
from lots of places and didn't want to touch such things unless
absolutely required)
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.
Requiring perl is indeed suboptimal, but on the other hands it's really
part of the default installation in 99% of all distros, and just about
the same percentage of projects require perl already. But I understand
that this is unwanted :)
While such a system is unusual, it made me very aware that the area of
child processes in Unix (ignoring windows) is very flexible and not
always fully standardised ( eg Linux pre 2.6 is not exactly POSIX).
Remember even if it doesn't run something remote, a build could easily
spawn background processes that can't be killed from the parent
because they are not part of the same process group, so if the perl
function only kills the group it still won't get them.
And your killall only works because you know that you are the only
make running on your machine, it would be considered impolite if you
were to kill someone else's make by accident :-)
I know, hence I'm searching for something better. See, I'm running a
rockbox build client. Natually, I will kill those makes too if it was
running at this very moment.
Its an area where caution is required to avoid real problems. If you
have a solution that works for you, great!! Configure it for yourself,
but it can't be offered as a general solution unless safe (oh, and
useful ;-)
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?
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?
I think we need to consider this a bit more first to find a safe
general solution.
In the interim why don't you configure an extra execute command to run
the "killall -9 make". It can then run asynchronously whilst the
build is running.
Because my run (and build) command list is full ;)
I keep running out too :-D
With the build-system branch the hidden preference
number_exec_menu_items can be set to increase the number of execute
commands, see the build-system version of geany.html preferences file
format section.
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!
Filetype and non-filetype numbers can also be increased so you can add
make commands too (you can't decrease them). Close and re-open Geany
before they take effect.
Cheers
Lex
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
