I've added a 'flush' method to the KernelManager here:<br><br><a href="http://github.com/epatters/ipython/commit/2ecde29e8f2a5e7012236f61819b2f7833248553">http://github.com/epatters/ipython/commit/2ecde29e8f2a5e7012236f61819b2f7833248553</a><br>
<br>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. <br><br>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. <br>
<br>Evan<br><br><div class="gmail_quote">On Wed, Jul 14, 2010 at 4:21 PM, Evan Patterson <span dir="ltr"><<a href="mailto:epatters@enthought.com">epatters@enthought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Wed, Jul 14, 2010 at 2:10 PM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>On Wed, Jul 14, 2010 at 10:56 AM, Evan Patterson <<a href="mailto:epatters@enthought.com" target="_blank">epatters@enthought.com</a>> wrote:<br>
> Hi guys,<br>
><br>
> I've been making decent progress at connecting my FrontendWidget to a<br>
> KernelManager. I have, however, encountered one fairly serious problem:<br>
> since the XREQ and SUB channels of the KernelManager are in separate<br>
> threads, there is no guarantee about the order in which signals are emitted.<br>
> I'm finding that 'execute_reply' signals are frequently emitted *before* all<br>
> the output signals have been emitted.<br>
<br>
</div>Yes, that is definitely possible and we really don't have control over<br>
it.  Part of the difficulty is that the SUB/SUB channel does buffering<br>
of stdout/stderr (just like sys.stdout/sys.stderr).  While it will<br>
make your application logic more difficult, I think this is something<br>
fundamental we have to live with.  Also, I wouldn't be surprised if<br>
the same were true of the regular python shell because of the<br>
buffering of stdout.<br></blockquote></div><div><br>I'm not sure it's fair to call this problem fundamental (if we ignore the corner case of the threads in the kernel). After all, output and execution completion happen in a very predictable order in the kernel; it's only our use of multiple frontend-side channel threads that has complicated the issue.<br>

</div><div><br>In a regular same-process shell, this wouldn't be a problem because you would simply flush stdout before writing the new prompt. It makes sense to be able to request a flush here, I think. A 'flush' in this case would just consist of the making the SubChannel thread active, so that its event loop would pick up whatever it needs to. I believe calling time.sleep(0) once in the XReqChannel before sending an execute reply will be sufficient. The latency introduced should be negligible. I'll experiment with this.<br>

<br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> It seems to me that we should be enforcing, to the extent that we can (i.e.<br>
> ignoring threads in the kernel for now), the assumption that when<br>
> 'execute_reply' is signaled, all output has been signaled. Is this<br>
> reasonable?<br>
<br>
</div>I don't think so.  I would write the frontend to allow for arbitrary<br>
timing of the execute_reply and the SUB messages.  You will have to<br>
use the parent_id information to order things properly in the GUI.<br>
Does this make sense.  I think if we try to impose the timing of the<br>
signals, we will end up breaking the model or introducing extra<br>
latencies.  Let us know if you have questions.  I know this will<br>
probably be one of the more subtle parts of the frontend logic.<br></blockquote></div><div><br>Yes, this is something that will be quite difficult to get right. For frontend implementors who are interested only in console-style interaction, it doesn't make sense for them to have worry about this.<br>
<font color="#888888">
<br>Evan<br> </font></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Cheers,<br>
<br>
Brian<br>
<br>
<br>
<br>
<br>
> Evan<br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Brian E. Granger, Ph.D.<br>
Assistant Professor of Physics<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu" target="_blank">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a><br>
</font></blockquote></div></div><br>
</blockquote></div><br>