[IPython-dev] Kernel-client communication
MinRK
benjaminrk at gmail.com
Thu Sep 9 18:47:43 EDT 2010
On Thu, Sep 9, 2010 at 13:46, Robert Kern <robert.kern at gmail.com> wrote:
> On 9/9/10 2:48 PM, Almar Klein wrote:
> >
> >
> > On 9 September 2010 16:58, Robert Kern <robert.kern at gmail.com
> > <mailto:robert.kern at gmail.com>> wrote:
> >
> > On 9/9/10 5:42 AM, Almar Klein wrote:
> > > Hi,
> > >
> > > > But thanks for your feedback and ideas: only if we can explain
> and
> > > > clarify our thoughts sufficiently to justify them, can we be
> sure that
> > > > we actually understand what we're doing.
> > >
> > > Hehe, I can imagine you (or others reading this thread) start to
> think I'm
> > > stubborn. Well I'm a bit of a purist at times and I keep to my
> opinion unless
> > > I'm convinced by good arguments :) But hey, its your project, so
> please
> > let me
> > > know if you've had enough of my criticism.
> > >
> > > So here's a little more ...
> > >
> > > > * I really think you can do with less sockets. I believe that
> the (black)
> > > > req/rep pair is not needed. You only seem to use it for when
> raw_input is
> > > > used. But why? When raw_input is used, you can just block and
> wait for some
> > > > stdin (I think that'll be the execute_request message). This
> should not be
> > > > too hard by replacing sys.stdin with an object that has a
> readline method
> > > > that does this. If two users are present, and one calls
> raw_input, they can
> > > > both provide input (whoever's first). To indicate this to the
> *other* user,
> > > > however, his prompt should be replaced with an empty string, so
> his cursor
> > > > is positioned right after the <text> in raw_input('<text>').
> > >
> > > Keep in mind that the direction of those sockets (the normal
> xreq/xrep
> > > pair for client input and the req/rep for kernel stdin) is
> opposite,
> > > and that's because they represent fundamentally different
> operations.
> > >
> > >
> > > I get that, but I'm not sure whether this is correct/necessary for
> the
> > > raw_input. In the original Python interpreter, raw_input just
> reads from
> > stdin,
> > > the same stream that's used for executing commands. The
> interpreter just
> > waits
> > > for the next "command", which is then interpreted as text, rather
> than
> > executing
> > > it. In a shell, this idea works quite well.
> >
> > Sending a command to the interpreter and sending input to raw_input()
> are
> > conceptually two different things. By keeping the interfaces for them
> separate,
> > we allow a greater flexibility to present different things in
> different ways.
> > Just because the original interpreter implementation conflated them
> out of
> > necessity due to the limitations of a terminal environment doesn't
> mean that is
> > the best thing to do. That would lock us down to the limitations of
> the original
> > implementation.
> >
> >
> > Fair enough. But what about my second argument: why can commands be
> executed by
> > all clients, but a response to raw_input only from one?
>
> That may be a reason to turn that into an XREQ socket on the kernel and
> XREP
> socket on the frontends, submitting one XREQ message to each frontend, and
> letting the first response "win", but it doesn't let you reuse the
> kernel-XREP/frontend-XREQ pair of sockets for this purpose.
>
It probably shouldn't be XREQ on the Kernel, because then raw_input requests
would be load balanced across clients, which doesn't really make sense. If
it's XREP on the Kernel, then the kernel could explicitly request raw_input
from the client who caused the prompt.
In fact, the broken load-balanced case is the current behavior (even on
REQ/REP sockets) when multiple frontends are connected, so this should be
listed as a bug, since as it stands, raw_input is broken for multiple
clients.
Using an XREP socket as a keyed requester rather than replier does require a
certain amount of zmq.IDENTITY bookkeeping, as I well know from using them
in exactly this way in the Parallel IPython code, but I think it's the right
approach here, unless you really want to solicit raw_input from everybody
(note that most clients will have no information about what is causing the
raw_input call they just received until *after* entering the input), which
would more appropriately require a two-socket PUB/SUB model.
-MinRK
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
> that is made terrible by our own mad attempt to interpret it as though it
> had
> an underlying truth."
> -- Umberto Eco
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100909/1e275ad9/attachment.html>
More information about the IPython-dev
mailing list