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

[Adam Olsen]

On Dec 6, 2007 9:56 PM, Sean Reifschneider <jafo-python-dev at tummy.com> wrote:
> 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.

That's pretty much what issue1564547 does.  I think there's two marks
against it:
* Using poll and fd's is pretty platform specific for what should be a
general-purpose API
* Handling signals is icky, hard to get right, and nobody trusts it

Since I don't think there's any more immediate solutions I'll provide
a plan B: my threading patch[1] will have a dedicated signal handler
thread, allowing them to be processed regardless of one blocked
thread.  I'm also providing an interrupt API the gtk bindings could
use to support wakeups, while keeping the poll+fd details private.


[1] http://code.google.com/p/python-safethread/
  The patch is, of course, out of date.

-- 
Adam Olsen, aka Rhamphoryncus