[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

Sean Reifschneider jafo-python-dev at tummy.com
Fri Dec 7 05:56:06 CET 2007


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 <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
      Back off man. I'm a scientist.   http://HackingSociety.org/



More information about the Python-Dev mailing list