<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
As he mentioned, Dave Scherer is traveling this week and will look in
only occasionally. He sent me a copy of a note that I'm convinced he
meant to post to the list but apparently sent only to Tal Einat. I
wrote to Dave to ask if this is what happened, but haven't heard back,
so in the interests of keeping the conversation going I've copied his
note below, as it may partly address Doug's question.<br>
<br>
I'll say again that what Dave is trying to restore to IDLE is what
works well in our big classes. It was a serious step backward for us
that this behavior changed. I didn't identify what was wrong, thinking
it was a VPython problem rather than an IDLE problem.<br>
<br>
Bruce Sherwood<br>
<br>
P.S. I don't know whether this is a separate issue or not, but it used
to be that one could start an IDLE editing session by right-clicking
the .py file on Windows. But currently what happens is that you can run
VPython just once; a second attempt kills everything.<br>
<br>
Douglas S. Blank wrote:
<blockquote
cite="mid:49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu"
type="cite">
<pre wrap="">Hi, Bruce. I'm familiar with VPython and think it is great. It would be
wonderful to get this kind of detailed feedback from real classroom use
into IDLE.
Your use of IDLE, like ours, required some similar changes. Perhaps Dave
can list out, point by point, the changes the patch makes, and we can
discuss those?
I'd be in favor of IDLE instantly killing the shell on exit, and for
making it generally more useful for VPython (and for us). In fact, I'm
going to try the patch tonight to see if it would work for our uses too.
Perhaps we can get rid of our hacks in favor of a general solution. (I
think that Tal incorporated a version of F5 that only reloaded the module
and didn't restart the shell. But I just downloaded Python2.5 for Windows
and see that IDLE is still version 1.2.2 :( )
Thanks,
-Doug
>From David Scherer to Tal Einat:</pre>
<div class="moz-text-html" lang="x-western">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is
this really wanted behavior? Isn't killing processes with SIGKILL<br>
considered bad practice, to be used only when you *really* *must* have<br>
the process terminate *now*? (I honestly don't know this, if someone<br>
knows - please answer.) Similarly, are we sure that TerminateProcess<br>
on Windows doesn't have any side-effects?</blockquote>
<div><br>
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.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> The Windows change is especially important,<br>
> because without it IDLE rather often fails to end my programs in a
timely<br>
> fashion when I close the output window, restart the shell, or just
press F5<br>
> to run the program again. I think, however, that the behavior on
all<br>
> platforms should be to terminate the user program immediately
whether or not<br>
> it cooperates; that's what I expect when I give such a command to
an IDE,<br>
> and a user program running disconnected from its output terminal
is not a<br>
> good thing.<br>
><br>
</div>
<br>
I'm not sure I understand what you mean - do you mean that you expect<br>
IDLE to shut down its sub-process immediately when you close it? Why<br>
does having the sub-process around for a few more seconds bother you?<br>
One could argue that it should be killed harshly if it does shut down<br>
cleanly in a minute or so, but that's not what you're proposing - if I<br>
understand correctly, you want it killed immediately no matter what.</blockquote>
<div><br>
Yes. There are several good reasons:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4. The user already has a way to "soft" break a program, which is
Ctrl-C in the output window.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">IIRC
the timeout is there for a reason, although it doesn't come to<br>
mind ATM. Perhaps Kurt or one of the other more senior IDLE developers<br>
</blockquote>
<div><br>
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 :-)<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You
also have a bug - the second place where you check for an<br>
ImportError you're not setting the correct variable (SIGTERM instead<br>
of SIGKILL).<br>
</blockquote>
</div>
<br>
Yes, indeed, thank you! As I said, I can't test the "unix" path, but I
should have caught that.<br>
<br>
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!)<br>
<br>
I'm travelling; I'll try to keep in touch but I can't promise.<br>
<br>
Dave<br>
</div>
</blockquote>
</body>
</html>