[Idle-dev] IDLEfork / Windows

[Kurt B. Kaiser]

After cleaning up the termination code, studying the Thread-SIG and
Python-dev archives, and experimenting with various threaded
approaches, the situation appears to me to be as follows:

1. The Linux implementation is working fine with SIGINT, pass loop
   code can be interrupted with a KeyboardInterrupt and the remaining
   environment examined with the shell.

2. Windows subprocesses can't be interrupted using signals in standard
   Python, as far as I can tell.

3. Therefore, subprocesses in Windows have to be controlled via RPC
   messages.  However, a subprocess which is not doing RPC I/O will
   not be listening to the socket because the single thread of control
   is in the user code, and can't be interrupted.  If the IDLE GUI
   process drops the link, the subprocess continues on its merry way
   and has to be killed manually with the Windows Task Manager.

4. Therefore, it is necessary to thread the subprocess on Windows.
   However, even after doing this there is no mechanism in Python to
   interrupt the user thread or even request it to (clean up and)
   exit, though the interpreter is servicing both threads with no
   difficulty.

5. If the subprocess is threaded and the user thread is
   setDaemon(True), it is possible to shut it down by doing a
   sys.exit() in the main thread.  When the GUI detects that the
   link has been dropped, it will spawn a new subprocess.  Though you
   can no longer examine the remaining environment, you will be able
   to continue your work, and there will be no errant processes.

6. To maintain fullest possible utility, the subprocess will be
   threaded under Windows, and not threaded on other platforms.

This is the direction in which I'm headed, pending an implementation of
PEP 42 / SF221115.

Am I missing something?  Is this the optimum approach?  Any comments
would be appreciated.

--
KBK