[IPython-dev] ctrl+c in gui, event loops, sure i'm missing something...

Ville M. Vainio vivainio at gmail.com
Thu Feb 12 06:16:00 EST 2009


On Thu, Feb 12, 2009 at 10:52 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> I am convinced the solution is going to multiple processes. Actually the
> important thing is to have multiple virtual machines between which we
> share a limited amount of states. Going multi-process is a simple way of

I agree that multi-process approach is the way to go, when ipython
does not need to access the gui directly (i.e. you can't do rapid gui
code prototyping). But the whole thing should not be overly
complicated since we already have multiple gui frontends - and all
they do is in essence passing strings around (text to execute, text to
display). It shouldn't really be that problematic to put a process
boundary in between. Perhaps the key is to avoid using sockets and
such, but just

- Launch frontend
- From frontend, launch backend using subprocess.Popen (or QProcess, or ...)
- Everything going to stdout can be displayed normally on frontend,
unless it's something special like get_completions_reply data
structure. We don't need to do any stdout redirection because
subprocess launch did it already
- On ctrl+C / interrupt button, send SIGINT to backend
- Standard input will be special, because it may contain "control"
commands like get_completions('foo...') that require special handling
- On linux, we could experiment with pty's to make the subprocess responsive

Perhaps the backend will benefit from a twisted mainloop that can hook
into stdin? And in any case, I think we *do* want some kind of
mainloop in the backend to avoid threads as much as possible.

Pros/cons of this approach:

Pros:

- No stdout/stdin redirection/capture code in frontend. It's just
normal pipe handling.
- Can be done as a library (no changes needed for ipython core)
- Launched processes (in backend) should behave naturally with the
stdin/stdout, since they inherit the pipe from ipython backend
process. IPython backend process itself can safely block waiting for
command to finish. No control commands should be sent to ipython
process while it's blocking, since they would be sent to launched
slave process instead. raw_input() in %run'd scripts should work fine
as well

Cons:

- Ptys are platform specific (i.e. the windows implementation may have
less "interactive" feel")
- Can't reconnect to backend if frontend crashes
- Probably other nasty issues that show up only when it's done

-- 
Ville M. Vainio
http://tinyurl.com/vainio



More information about the IPython-dev mailing list