[IPython-dev] Coordinating the XREQ and SUB channels

[Evan Patterson]

On Thu, Jul 15, 2010 at 12:44 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Thu, Jul 15, 2010 at 9:23 AM, Evan Patterson <epatters at enthought.com>
> wrote:
> > I've added a 'flush' method to the KernelManager here:
> >
> >
> http://github.com/epatters/ipython/commit/2ecde29e8f2a5e7012236f61819b2f7833248553
> >
> > It works, although there may be a more intelligent way to do it. That
> being
> > said, I tried a number of different things, and none of the others
> worked.
>
> The only issue that I see with this is that if the SUB channel keeps
> getting incoming message, flush will not return immediately.
>
> > Brian: since the 'flush' method must be called explicitly by clients,
> this
> > won't break our model or extra induce latencies for clients that want to
> > take a more sophisticated approach to SUB channel monitoring.
>
> That is true, so I think it this helps you to get going, it is worth
> using for now.  But, I still don't see why we reorder the messages in
> the frontend based on the parent_ids.  Just so you know, Fernando and
> I have set aside time starting this Sunday to work extensively on
> this.  At that time we can talk more about this issue.
>

Just to clarify: the issue isn't so much that the message themselves have to
be reordered, but what this implies for the text widget update. Currently, I
more or less blindly append text the end of text widget buffer as I go. To
support arbitrary order insertion, I would have to have a mechanism whereby
blocks of texts are tagged according to the message that they correspond to.
Then, whenever output messages come in, I would have to find the correct
spot to insert them. Since this is considerably more complex than just
calling 'flush', doing this the "right" way is not a priority until more
important things get done.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100715/6f8b78c1/attachment.html>