On Thu, 2010-12-30 at 14:09 -0300, Juan Manuel Santos wrote:
> Is this useful? I just ran "strace python algo.py", sorry if I am
> quite a rookie with strace, never really used it a lot.
It sort of confirmed by suspicion that it was busy-polling on a
non-blocking file descriptor, but the actual details are a bit
surprising.
I'm able to reproduce the problem now using stock pygtk 2.17, so I can
see what's going on here. pygtk 2.17 does have support for
PySignal_SetWakeupFd, but it seems to be broken. gtk is polling the
read half of the pipe properly, but when Python writes to the write half
of the pipe, pygtk is failing to pull that data out of the pipe.
Instead it's calling read() on the socket used for X communication,
which is non-blocking, even though poll() never saw any activity on that
fd, so read() returns EAGAIN.
Since poll() is level-triggered, every call immediately returns saying
"hey there is data on the wakeup pipe" but pygtk never reads from it.
This results in the busy loop.
This doesn't have anything to do with kaa. You can reproduce it in your
test case by removing all references to kaa and just attaching a dummy
SIGCHLD handler:
signal.signal(signal.SIGCHLD, lambda *args: None)
Attaching a handler causes Python to hook its C handler, which gets
invoked on SIGCHLD, which writes the byte to the wakeup fd (as
instructed by pygtk).
The fact that it works with kaa.main.run() is because
pygtk_main_watch_prepare() never gets called (while it _does_ get
called with gtk.main()) and so the wakeup fd is never set, bypassing the
bug.
So this is clearly a bug in pygtk that's since been fixed (and some
distros like Ubuntu have backported the fix). Still, I think it's A Bad
Thing that kaa automatically attaches signal handlers at import time
(whether that's a lazy import or not). I'm going to work on fixing
this, but it requires a bit of rejigging some of the core guts so I need
to be a bit careful.
In the meantime, you have 3 options:
1. Use a newer version of pygtk (or a version with the wakeup fd
fix backported).
2. Use svn kaa.base which does lazy importing. The problem occurs
when kaa.process gets imported, since it adds the SIGCHLD
handler.
3. Use kaa.main.run() instead of gtk.main() to start the mainloop.
Cheers,
Jason.
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
