[IPython-dev] Coordinating the XREQ and SUB channels
Fri Jul 16 11:00:25 CDT 2010
Here is the commit:
You will need to recompile pyzmq for this to go into affect. Let me
know if this doesn't fix the problem.
On Fri, Jul 16, 2010 at 7:40 AM, Evan Patterson <firstname.lastname@example.org> wrote:
> On Fri, Jul 16, 2010 at 12:25 AM, Brian Granger <email@example.com> wrote:
>> On Thu, Jul 15, 2010 at 1:22 PM, Fernando Perez <firstname.lastname@example.org>
>> > On Thu, Jul 15, 2010 at 11:07 AM, Brian Granger <email@example.com>
>> > wrote:
>> >> Definitely hard to get right and terminal based frontends will
>> >> definitely need something like flush. Let's see how it goes with this
>> >> approach.
>> > Though absent a real event loop with a callback model, there it will
>> > need to be implemented with a real sleep(epsilon) and a total timeout.
>> > Terminal frontends will always simply be bound to flushing what they
>> > can and then moving on if nothing has come in a given window they wait
>> > for. Such is life when your 'event loop' is the human hitting the
>> > RETURN key...
>> > Evan, quick question: when I open your frontend_widget, I see 100% cpu
>> > utilization all the time. Do you see this on your end?
>> We should make sure we understand this. Min and I found that our new
>> Tornado event loop in pyzmq was using 100% CPU because of a bug in the
>> poll timeout (units problems). We have fixed this (so we think!), so
>> I am hopeful the current issue is coming from the flush logic.
> Unfortunately, this does not seem to be the case. I have confirmed that the
> problem is indeed with the IOLoops. They have the the CPU pegged at 100%
> even when the console is idle, i.e. when no flushing or communication of any
> sort occurring.
> Did you commit your fix to the main branch of PyZMQ? Maybe I am not using
> the right stuff.
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev