python activities startup

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Feb 7 11:46:52 EST 2008


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

On Wed, 06 Feb 2008 at 23:06:19 -0500, Michael Stone wrote:
> Next, according to dbus-python's dbus/_dbus.py, the SessionBus returned
> when you call SessionBus() is cached in 
> 
>   Bus._shared_instances[BUS_SESSION]

This is not an API guarantee; neither is it API at all. I accept no
responsibility if the entire platform mysteriously crashes after a
dbus-python upgrade...

It ought to be sufficient for Rainbow to call close() on the SessionBus
after forking, but before executing the "target" code. This should remove it
from _shared_instances automatically, causing subsequent calls to SessionBus()
to create a new instance, although that code-path is not well tested and you
might need some patches or a newer version of dbus-python.

A better solution would be for Rainbow to avoid SessionBus() entirely,
and instead use an instance of the superclass, dbus.bus.BusConnection. This
does not have the weird caching behaviour at all (one call to the
constructor = one instance = one D-Bus connection). The code that gets run
after forking is still free to use the shared SessionBus.

This may require some care in the libraries that Rainbow uses - they
should all be able to accept a BusConnection argument rather than
implicitly using the shared SessionBus, but they don't necessarily get
this right. Libraries that can only use the shared SessionBus should
probably be considered buggy anyway, though.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHqzX8WSc8zVUw7HYRAg6uAJ0XPz2C0az/DQ1XCAqNXZokzgFpeACdEfT3
MCpT4HahnUjTgG/rN1UFELw=
=zVsd
-----END PGP SIGNATURE-----



More information about the Devel mailing list