[patch] Python-dbus finish implementing deferred methods

Simon McVittie simon.mcvittie at collabora.co.uk
Wed Jan 17 06:23:47 PST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 15 Jan 2007 at 14:16:07 -0600, tsuraan wrote:
> >I'm not sure that I understood that. Could you provide a simple test case
> >that
> >should work, but doesn't, and describe what it ought to do?
> 
> 
> Ok, this is a little ugly, but it's as simple as I can get it...

(Slow.py, Caller.py, test.py with slightly more debug copied to
http://people.freedesktop.org/~smcv/temp/d-p-threaded-blocking/ for
list's benefit)

> tsuraan at localhost ~/test/python/dbus/blocking $ python Slow.py & python
> Caller.py &
> [1] 8636
> [2] 8637
> tsuraan at localhost ~/test/python/dbus/blocking $ python test.py
> call took 5.00829911232 seconds
> 
> One would expect the call to have taken about one second, but instead it
> takes five.  It looks like the first dbus method in Caller cannot return
> until its call has completed.  Is that a bug, or is that a part of the
> spec?  Or, is this a glib problem, and I should ask them about it?  It
> doesn't really look like glib and python threads play very nicely together,
> so maybe that's the problem.

The issue is that Caller is making a blocking D-Bus call. In libdbus,
blocking calls block their thread (without re-entering the main loop);
Connection methods also lock the connection, which means that most other
methods on that connection (including normally non-blocking calls) will block.

You can avoid this by not sharing a Connection (or Bus, which is a
subclass) between threads, or by making all your calls asynchronously
(see examples/example-async-client.py and/or doc/tutorial.txt in git).

In some future version of dbus-python I want to offer the option of
having "blocking" calls do their blocking by re-entering the main loop,
perhaps with a keyword argument reenter=True. I'm not sure whether it should
be on by default or not - either way sometimes gives you surprising results.
Probably off by default would be better, since that's what dbus-python has
always done.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFFrjFzWSc8zVUw7HYRAqt/AJ9lI5B1uhmluwKemqB9+OOT8uW3mQCgl3Np
aHwJMXnoqTYP0DONIp5PaHQ=
=RTow
-----END PGP SIGNATURE-----


More information about the dbus mailing list