[Idle-dev] RPC Investigations

[Kurt B. Kaiser]

I spent some time comparing the four versions of Idle.

Python Idle, as expected, runs in one process.  It can be difficult to
break into a tightly looping "pass" loop.

I recreated GvR's version of Python Idle with his RPC changes.  This,
again as expected, runs in two processes.  One owns the Shell and any
other edit windows, the other is the execute server.  When the code in
the edit window is run, the output appears in the Shell.  The remote
environment is not cleared between runs as yet.  It is easy to break
into a tight loop with ctrl-c.

Idlefork with DS RPC: Starting an edit window causes three processes
to listen on port 7454.  Only one gets any cpu cycles.  When you start
a Shell, and run an empty loop, the execution is handled locally by
that same process.  Running code from the edit window causes an
additional five processes to start up.  One of these is accessing X
resources and one is the remote server.  The other three don't get any
cycles.  The Shell continues to execute locally and does not know
about the client/server process or the program is is running.  The
environment can't be inspected and all state is lost between runs.  It
is difficult to break a tight loop.

Idlefork with GvR RPC as checked in by Chui: Get the same 3 and 5
processes, when run without -r, it's using the DS RPC.  When run with
the -r and a script it uses GvR RPC and starts up a Shell and an edit
window using three processes.  When code is executed in the Shell, one
new, smaller process is created which handles the remote computation.
Display is in an output window, not the Shell, "interactive" code is
split between the Shell and the output window.  State is maintained
between runs.

In all four versions of Idle a print loop is limited by the scrolling
speed of the Tk widget once the window fills up, and they all have
similar performance, limited by X/Tk.


Having both DS RPC and GvR RPC in the same code is quite confusing and
difficult to debug.  Also, we want the Shell to process remotely,
receive its own output and be able to inspect the environment after
code is executed.  

So I bit the bullet and reworked the code to have only the GvR RPC,
and with output to the Shell instead of a separate output window.  It
works very much like Python Idle at this point, except that execution
is remote and the GUI is enhanced by Stephen's changes.  There are two
processes, all user code is executed remotely, and state is
inspectable by the Shell.  The remote server is not yet restarted
following an F5 invocation. 

That is what I'm checking in tonight on the MAIN branch.

The stack viewer is working now.  Next, get the remote debugger
working.

KBK