[IPython-dev] ctrl+c in gui, event loops, sure i'm missing something...
Ville M. Vainio
Thu Feb 12 14:52:28 CST 2009
On Thu, Feb 12, 2009 at 10:23 PM, Brian Granger <firstname.lastname@example.org> wrote:
>> - Implement something like ipy_server or ipy_vimserver that uses
>> stdin, stdout+stderr for communication.
> These don't use stdin/stdout for communication. They use Unix
> sockets. Plus, this is an unsafe thing to do (yes our current
True, and I'd like to change them to use just natural pipes that come
from process startup. Well, actually I won't be using in code in
ipy_*server at all, since I want to avoid threads. Other forms of IPC
are easier to wrangle, but I just want to retain a tight connection
with the processes by using these "natural", inherited pipes. They are
also necessary for subprocesses launched by the backend.
And it's not like I couldn't add another socket connection to the game
if need arises ;-).
> versions have this problem). Here is why. These codes run an event
> loop in a thread. They then call the ipython0 core from that thread.
Yeah, no thread will enter my implementation. ipy_server.py was just a
quick hack I did to prove some point, iirc).
> I think stdin/stdout should be reserved for the usual meanings. There
But the idea here *is* to use them for their usual meaning, with some
extra features added.
> are many robust ways of doing IPC over various types of sockets that
> should be used instead for control. This is what things like
> vim_server do already - we just need to think carefully about how we
> can make these things thread safe.
Those scripts don't really do that much. I think that by hooking all
the three I/O sockects we will have something much more interesting.
These scripts could be mado threadsafe by removing threads from them.
Threading was just the easy way to write such scripts, but without
much work you could throw in asyncore or twisted.
Ville M. Vainio
More information about the IPython-dev