[IPython-dev] Kernel-client communication

[MinRK]

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>