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

[Jan Lübbe]

On Fri, 2008-10-24 at 12:15 +0100, Simon McVittie wrote:
> 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.

I didn't know that libdbus used asserts for catching "external"
programming errors and expected it to indicate an (recoverable) error.
This makes it a bit more complicated. :/

> 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.

To me this seems to be a shortcoming of libdbus. Wouldn't this checking
be more useful there instead of in dbus-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.)

Is dbus_connection_register_object_path the only "dangerous" API? In
that case i could live with being careful to not pass the same object
path twice.

> 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.

Is this your long-term goal? I hoped to be able to prototype in Python
and then move performace critical code into extension modules...

> 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'll take a look at this, thanks.

> 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.

Is there another way i overlooked to offer objects on the same
well-known bus name from different connections (in the same process)?

> (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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-- 
Jan Lübbe <jluebbe at lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E