[Idle-dev] Fix for long delays

[Tal Einat]

David Scherer wrote:
> Here is a patch to the IDLE shipped with Python 2.5.2 that I regard as a bug
> fix.  Specifically, it makes IDLE terminate its subprocess on Windows with
> TerminateProcess (instead of just by closing a socket), and on UNIX with
> SIGKILL instead of SIGTERM.

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?

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

> I'm working on Windows at the moment, so I'd greatly appreciate it if
> someone on the list can test my changes on a platform that has os.kill.
>
I'd be glad to test this on an OSX 10.5 box, once we agree on the
conceptual issues...

> I suspect that the code in run.py has some quirks that exacerbate the bad
> behavior without the patch (for example, why the 10 second timeout in
> MyHandler.exithook?), but my patch appears to make them irrelevant, as well
> as deal with really nasty ways that the running program could freeze itself
> up (e.g. a C extension that blocks without releasing the interpreter lock).
> If there are any platforms other than Windows without os.kill, it might be
> worth at least getting rid of the timeout.
>
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

> Comments or questions?
>

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

- Tal