[IPython-dev] Coordinating the XREQ and SUB channels

[Fernando Perez]

Hi Evan,

[ quick note, I'm cc-ing the ipython-dev list so these technical
discussions on the new code happen there, so other developers benefit
as well ]

On Wed, Jul 14, 2010 at 12:10, Brian Granger <ellisonbg at gmail.com> wrote:
> On Wed, Jul 14, 2010 at 10:56 AM, Evan Patterson <epatters at enthought.com> wrote:
>> Hi guys,
>>
>> I've been making decent progress at connecting my FrontendWidget to a
>> KernelManager. I have, however, encountered one fairly serious problem:
>> since the XREQ and SUB channels of the KernelManager are in separate
>> threads, there is no guarantee about the order in which signals are emitted.
>> I'm finding that 'execute_reply' signals are frequently emitted *before* all
>> the output signals have been emitted.
>
> Yes, that is definitely possible and we really don't have control over
> it.  Part of the difficulty is that the SUB/SUB channel does buffering
> of stdout/stderr (just like sys.stdout/sys.stderr).  While it will
> make your application logic more difficult, I think this is something
> fundamental we have to live with.  Also, I wouldn't be surprised if
> the same were true of the regular python shell because of the
> buffering of stdout.
>
>> It seems to me that we should be enforcing, to the extent that we can (i.e.
>> ignoring threads in the kernel for now), the assumption that when
>> 'execute_reply' is signaled, all output has been signaled. Is this
>> reasonable?
>
> I don't think so.  I would write the frontend to allow for arbitrary
> timing of the execute_reply and the SUB messages.  You will have to
> use the parent_id information to order things properly in the GUI.
> Does this make sense.  I think if we try to impose the timing of the
> signals, we will end up breaking the model or introducing extra
> latencies.  Let us know if you have questions.  I know this will
> probably be one of the more subtle parts of the frontend logic.
>
> Cheers,
>
> Brian
>
>
>
>
>> Evan
>>
>
>
>
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
>

I was in the middle of writing my reply when Brian's arrived pretty
much along the same lines :)

The parent_id info is the key: clients should have enough information
to reconstruct the chain of messages with this, because every message
effectively has a 'pointer' to its parent.  It's possible that we may
need to extend the message spec with a bit more data to make this
easier, if you spot anything along those lines we can look into it.
We cobbled together that message spec very quickly, so it should be
considered by no means final.

But the key idea is always: a client makes a request, and all outputs
that are products of honoring this request (on stdout/err, pyout, etc)
should have enough info in the messages to trace them back to that
original cause.  With this, the client should be able to put the
output in the right places as it arrives, since it can reconstruct
what output goes with what input.

The simplest example of that is what we showed you with two terminal
clients talking to the same kernel, where each client would show the
other's inputs and outputs with [OUT from ...] messages.  The client
was receiving *all* outputs on its SUB socket, and disentangling what
came from its own inputs vs what was input/output from other clients
running simultaneously.

Let us know if this is clear...

Cheers,

f