[PATCH] Add a Connection.get_c_connection() method which returns the DBusConnection pointer

[Simon McVittie]

On Thu, 23 Oct 2008 at 22:17:14 +0200, Jan Luebbe wrote:
> Using the same well-known bus name from native Python and
> extension modules at the same time is only possible with the same
> connection.

Sorry, I don't think that's safe. dbus-python goes to great lengths to avoid
libdbus asserting and killing the process, but it can only do this by
knowing that it is the only user of the DBusConnection. It's not
possible to prevent two modules that share a DBusConnection from causing each
other to assert libdbus, for instance by both calling
dbus_connection_register_object_path() with the same object path.

This violates a principle I was trying to follow, which is that however many
programming errors a Python programmer makes, they shouldn't be able to
trigger fatal assertions in pure Python.

(A while ago I added some new API in libdbus -
dbus_connection_try_register_object_path - which might help to solve
this. dbus-python doesn't use it yet, though - patches welcome. Sorry,
I've not had a lot of time to hack on dbus-python or libdbus.)

If dbus-python ever moves from being a libdbus binding to being a pure-Python
D-Bus implementation (like dbus-java, ndesk-dbus, and the Ruby binding whose
name I can't remember right now), this will become impossible in any case.

The 'purity' branch in git (which I've never quite dared to merge without
a third-party review) takes some steps towards this by stopping using
dbus_connection_register_object_path and just adding a filter instead. This
still uses libdbus for authentication and stuff, but allowed me to delete a
lot of paranoid code that attempted to manipulate the libdbus object tree in
an assertion-free way, in favour of reimplementing it in some quite simple
Python (the Python code to make my own object tree is about half the length of
the C code necessary to tiptoe around libdbus).

> +PyDoc_STRVAR(Connection_get_c_connection__doc__,
> +"get_c_connection() -> long\n\n"
> +"Return the address of the DBusConnection C struct. This can be use to pass a\n"
> +"connection to an external C library.\n");

C code is able to access the DBusConnection already, by using
#include <dbus/dbus-python.h> (it's not really documented, but see the
header file and the _dbus_glib_bindings module for example usage - the
function is something like DBusPyConnection_BorrowDBusConnection). Do
this at your own risk...

I don't think pure-Python code should be able to access the C internals of
dbus.Connection, so even if sharing a DBusConnection was safe, I would
prefer to avoid adding this method.

(The stuff with macros and a PyCObject in <dbus/dbus-python.h> is
strange, I will agree, but it's the canonical way to provide a C API for
CPython extensions, due to symbol visibility issues on some non-Linux
platforms.)

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20081024/92acdec3/attachment.pgp