[Idle-dev] Fix for long delays

[Tal Einat]

Douglas S. Blank wrote:
> On Mon, May 26, 2008 5:42 am, Tal Einat said:
>> 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?
>
> We have added very similar code to a startup wrapper around IDLE that does
> the same thing. We have the same situation where the serial port code
> talking to a robot in the background thread won't let go, and we have to
> kill it.
>
> However, this fix doesn't allow you to have two IDLE's running. The second
> one started will kill the first. In fact, ours kills all running Python
> processes---not generally a good idea.

In your case I understand the need, but this could be considered a
special use case - to add such a feature to IDLE we would need to show
that it would be generally useful.

> Having the background stop quickly would be useful.

Can you expand on this? In which cases would it be useful?

> I don't think I would add this patch to IDLE... too many side effects. I
> think I would fix it in other ways:
>
> 1) when closing idle, have it kill the one background process immediately.

Again - why immediately? Why not allow a certain delay, monitor the
sub-process, and only kill it if it is still running after the delay?
The duration of the delay could be configurable, and setting it to
zero would kill the sub-process immediately.

> 2) when starting IDLE, check for a running version, and have it open the
> file/use the current Python Shell. That would prevent starting multiple
> shells which are trying to do the same thing (ie, connect on to serial
> ports, etc).
>
> 3) allow idle to have multiple shells (in case you really do want to do that)

Hmm. I must say I don't really see the benefit here if you allow
multiple shells - you'd still have the same problems that you have
now. And if you only allow one shell, that's very restrictive - I'm
pretty sure we don't want to do that.

I can understand why in your specific case you would want #2 - you
want to ensure that there is only one IDLE shell. However, you're the
first I've ever heard wanting this from IDLE, whereas I know plenty of
users who often run multiple IDLE shells in parallel.

- Tal