Is
this really wanted behavior? Isn't killing processes with SIGKILL
considered bad practice, to be used only when you *really* *must* have
the process terminate *now*? (I honestly don't know this, if someone
knows - please answer.) Similarly, are we sure that TerminateProcess
on Windows doesn't have any side-effects?
As
far as I know, on all modern platforms killing a process is perfectly
safe, except that some processes may want to perform positive actions
in their shutdown process (logging, asking the user if they want to
save their work, informing a peer on the network, etc). All of these
are good reasons why for a user interacting with unfamiliar programs
they did not develop, SIGTERM is the right default. However, a user,
running a program they probably developed in a development environment
or debugger, expects "terminate" to mean "terminate", and there is no
reason to expect there to be negative side effects of doing this.
> The Windows change is especially important,
> because without it IDLE rather often fails to end my programs in a
timely
> fashion when I close the output window, restart the shell, or just
press F5
> to run the program again. I think, however, that the behavior on
all
> platforms should be to terminate the user program immediately
whether or not
> it cooperates; that's what I expect when I give such a command to
an IDE,
> and a user program running disconnected from its output terminal
is not a
> good thing.
>
I'm not sure I understand what you mean - do you mean that you expect
IDLE to shut down its sub-process immediately when you close it? Why
does having the sub-process around for a few more seconds bother you?
One could argue that it should be killed harshly if it does shut down
cleanly in a minute or so, but that's not what you're proposing - if I
understand correctly, you want it killed immediately no matter what.
Yes. There are several good reasons:
1.
The subprocess may have ongoing side effects besides just output in the
output window. In my particular world, this consists of displaying
user interface windows on the screen. These windows usually remain
(and are still interactive!) after the program has supposedly been
"terminated" by IDLE. Douglas gives another example. A program may
have locked files or other resources for exclusive access, so that it
fails on a second invocation if it's still running. Worse, it may open
files without locking them so that two running copies will interact in
a dangerous way. The user really wants "restarting" their program to
be a sequential process (stop, start) rather than a concurrent one! A
buggy process (remember, this is a _debugger_!) could theoretically be
deleting all your files, and when you ask IDLE to terminate it, it
won't do so reliably.
2. IDLE itself occasionally gets jammed up somehow when there are
unterminated subprocesses. I don't know a completely reliable way to
reproduce this behavior, but I often observe IDLE becoming completely
unresponsive for 10 seconds, while it waits for that timeout to expire
in a subprocess before creating a new one. I also occasionally see
error messages saying that the subprocess could not be created or a
connection could not be established. I don't know exactly what causes
these problems (there are far too few subprocesses even at the worst of
times to run my system out of ports or process handles) and perhaps
they could be fixed separately, but at least on Windows my patch
appears to fix this bad behavior completely.
3. In the case that you appear to be thinking of (programs that
have no side effects besides printing to standard output and standard
error), kill -9 or TerminateProcess is harmless. The behavior is
indistinguishible except for the CPU and memory usage of the zombie
program in the meantime, which could be significant.
4. The user already has a way to "soft" break a program, which is
Ctrl-C in the output window.
IIRC
the timeout is there for a reason, although it doesn't come to
mind ATM. Perhaps Kurt or one of the other more senior IDLE developers
I'm sure it's there for a reason, but as I say
above there is some bad behavior. But I'm not really personally
interested in fighting that issue if I can get my patch adopted :-)
You
also have a bug - the second place where you check for an
ImportError you're not setting the correct variable (SIGTERM instead
of SIGKILL).
Yes, indeed, thank you! As I said, I can't test the "unix" path, but I
should have caught that.
I
should add that this change is extremely important to me and to a
rather large community of VPython users using IDLE. I originally added
subprocess support to IDLE in order to make it a usable development
environment for programs (like VPython ones) that do things other than
print to standard output, that infinite loop, etc. For the environment
to be useful for our users, it needs to reliably and instantly restart
the user's program when they press F5. The current problems are
serious enough that if they aren't resolved somehow, we will be forced
to fork IDLE (again!)
I'm travelling; I'll try to keep in touch but I can't promise.
Dave
