Signals in Python without glib

[Justin Mazzola Paluska]

On Wed, Aug 02, 2006 at 06:58:22PM -0400, Havoc Pennington wrote:
> Justin Mazzola Paluska wrote:
> >
> >Once this while loop starts up, I can no longer make blocking function
> >calls in another thread.  Instead, CPU usage shoots up to 100%.  I
> >attached to the process with gdb and it looks the mainloop thread is
> >blocked on poll and the request thread is taking up all of the
> >processor time.  When I step through the code using gdb, it looks like
> >the request thread is stuck in a loop:
> 
> This has no hope of working reliably without the pending call locking 
> patch I posted recently, so step 1 is be sure you have latest dbus.

OK, installed from git.  Broke everything else on my system, but I can
at least run tests against it.

> Step 2 I think if you just step through the 100% cpu thread in gdb it 
> should be pretty obvious what happens...

It isn’t that clear to me.  It looks like it’s sitting in a tight loop
printing:

    "21410 waiting for IO path to be acquirable"

(where 21410 is the pid of the process).  Tracking this down to the
_dbus_connection_acquire_io_path function, I think what’s happening is
that threads are not initialized, so there’s no condvar for the wait
function to wait on, so it just loops.

So, what it seems I need to do is call dbus_threads_init.  My
application requires Python, so that means wrapping the
dbus_threads_init function (and the corresponding DBusThreadsFunction
struct) in Python.

After some business travel, I’d like to tackle this.  Do you have any
pointers on what’s the best way to expose the Python locking
primitives that the DBusThreadsFunction struct needs to DBus?  Or is
there a better, cross-platform, way to add them (without needing the
to dip into Python).

Now I see why everyone’s told to use the glib mainloop.  However, if
this is possible, the Python bindings are getting closer to having its
own thread-safe mainloop.
	—Justin