<div class="gmail_quote">On Wed, Jul 14, 2010 at 2:10 PM, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt;</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="im">On Wed, Jul 14, 2010 at 10:56 AM, Evan Patterson &lt;<a href="mailto:epatters@enthought.com">epatters@enthought.com</a>&gt; wrote:<br>
&gt; Hi guys,<br>
&gt;<br>
&gt; I&#39;ve been making decent progress at connecting my FrontendWidget to a<br>
&gt; KernelManager. I have, however, encountered one fairly serious problem:<br>
&gt; since the XREQ and SUB channels of the KernelManager are in separate<br>
&gt; threads, there is no guarantee about the order in which signals are emitted.<br>
&gt; I&#39;m finding that &#39;execute_reply&#39; signals are frequently emitted *before* all<br>
&gt; the output signals have been emitted.<br>
<br>
</div>Yes, that is definitely possible and we really don&#39;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&#39;t be surprised if<br>
the same were true of the regular python shell because of the<br>
buffering of stdout.<br></blockquote><div><br>I&#39;m not sure it&#39;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&#39;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&#39;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 &#39;flush&#39; 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&#39;ll experiment with this.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
&gt; It seems to me that we should be enforcing, to the extent that we can (i.e.<br>
&gt; ignoring threads in the kernel for now), the assumption that when<br>
&gt; &#39;execute_reply&#39; is signaled, all output has been signaled. Is this<br>
&gt; reasonable?<br>
<br>
</div>I don&#39;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><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&#39;t make sense for them to have worry about this.<br>
<br>Evan<br> </div><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>
&gt; Evan<br>
&gt;<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">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
</font></blockquote></div><br>