Overview (my reading of it): PyGTK wakes up 10x a second in it's main loop because signals may be delivered to another thread and will only get picked up if the mainloop wakes up.
In the following thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html it sounds like the patch at: http://bugs.python.org/issue1564547 doesn't solve the problem. A recent gnome bug brings this issue back up: http://bugzilla.gnome.org/show_bug.cgi?id=481569 I went ahead and closed the python issue as "rejected" to hopefully get some more activity on it. I thought about this some, and I wondered if there was some way we could signal the sleeping thread when a signal came in on another thread. Like perhaps we could make some code to create a pipe, and put it someplace that all threads could get access to. Then, if a thread gets a signal, write on this pipe. The mainloop could include this file descriptor in the set it's watching, so it would wake up when the signal came in. Is this something Python should provide, or something PyGTK should do? If an approach like the above would work, we could make it so that select() always created this file descriptor and added it to one of the FD sets, so that it would do the right thing behind the scenes. I have no idea if this is a reasonable approach, but it's something that came to mind when I thought about the problem and was an approach I didn't see mentioned before in the discussion. Thanks, Sean -- I live my life like I type; Fast with lots of mistakes. Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.org/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
