GNOME Bugzilla – Bug 401080
Add a generic signal marshaller
Last modified: 2011-06-20 15:03:51 UTC
Recently the GStreamer camp tried to prototype a new GObject class using a dynamic language binding (eg Python). The object written in Python would define properties and signals using the standard mechanism the language binding provides. However, it could not easily be done because the Python bindings lacked a way to provide a signal marshaller for code written in C. PyGObject uses the following piece of code to create a new signal: signal_id = g_signal_newv(signal_name, instance_type, signal_flags, pyg_signal_class_closure_get(), accumulator, accum_data, (GSignalCMarshaller)0, return_type, n_params, param_types); As you can see the c_marshaller is 0 and therefor applications in C will not be able to connect to that signal. I propose adding a generic C marshaller using a library like libffi to GObject, that would allow C code to use signals written using a language binding.
Or C/Invoke, which seems to be a maintained replacement for libffi. I hear Python uses a modified version of libffi maintained internally. Maybe glib can do the same.
Created attachment 81343 [details] [review] g_cclosure_marshal_generic implementation using C/Invoke Attached is a generic CClosure marshal handler implemented using C/Invoke. Adopting the implementation to use libffi instead of cinvoke would be mostly trivial since there's a similar existing implementation of that in gobject-introspection/src/ginvoke.c I can integrate the standalone program in glib if C/Invoke or libffi is an accepted as a dependency.
Created attachment 81376 [details] [review] test-invoke.c: libffi version Same as attachment 81343 [details] [review] but it uses libffi instead of C/Invoke.
Created attachment 81513 [details] [review] patch for gobject with tests included
Shouldn't the presence/absence of FFI be advertised in glibconfig.h?
I suggest including libffi unconditionally inside glib. Python has a copy, so it should be portable enough.
(In reply to comment #4) > Created an attachment (id=81513) [edit] > patch for gobject with tests included > This patch is outdated; it doesn't handle return arguments. PyGObject ships with an implmentation which handles that; http://svn.gnome.org/viewcvs/pygobject/trunk/gobject/ffi-marshaller.c?revision=651&view=markup
Perhaps this can be revisited now that libffi has made a stable 3.0 release http://sourceware.org/ml/libffi-announce/2008/msg00001.html
Created attachment 105381 [details] [review] v2 Attaching a new patch which is: * Updated to trunk * Using system libffi via pkg-config available in the new 3.0.x releases * Updated copy of the marshaller which actually marshalls the return values. The same libffi version has been included in pygobject for a while.
Exciting. I think we should provide this and possibly some other API exposing libffi functionality unconditionally, probably using an internal copy if needed, like we do for pcre.
(In reply to comment #10) > Exciting. I think we should provide this and possibly some other API exposing > libffi functionality unconditionally, probably using an internal copy if > needed, like we do for pcre. It would be better to just depend on libffi imho, the idea of the new 3.0 release was to reduce the number of external copies. But perhaps there'll be another 10 years before the next release... It's about 26k lines of code and 15ish supported platforms in the new release.
bug 496006 is related, allowing different linking options to libffi, which appears to be necessary on some systems.
+if HAVE_LIBFFI +libgobject_2_0_la_LIBADD += $(LIBFFI_LIBS) +libgobject_2_0_la_CFLAGS += $(LIBFFI_CFLAGS) +endif That's unnecessary, it doesn't need to be conditional. LIBFFI_LIBS and LIBFFI_CFLAGS will be empty if we didn't find a libffi in configure. So you can remove that as well: +AM_CONDITIONAL(HAVE_LIBFFI, $have_libffi) I'd add a variable to gobject's pkg-config though, so applications can require a gobject with libffi support. libffi is up to 3.0.6 [1], and the patch looks good. When can we get this in? [1]: ftp://sourceware.org/pub/libffi/
Just a note, gobject-introspection will depend on libffi. And my current Java bindings depend on JNA which depends on libffi. And someone should fix the bug that Python comes with an internal libffi..
Any chance we can get this in? Thanks
(In reply to comment #13) > +if HAVE_LIBFFI > +libgobject_2_0_la_LIBADD += $(LIBFFI_LIBS) > +libgobject_2_0_la_CFLAGS += $(LIBFFI_CFLAGS) > +endif > > That's unnecessary, it doesn't need to be conditional. LIBFFI_LIBS and > LIBFFI_CFLAGS will be empty if we didn't find a libffi in configure. Actually though, since this is something we expect infrastructure and apps to use, we can't just fail at runtime if it's not available or something. Basically the whole thing needs to be a hard requirement.
commit 88ab35f3cb6127036361e421987a127bddb989c8 Author: David Zeuthen <davidz@redhat.com> Date: Fri Apr 8 17:34:44 2011 -0400 Add a generic libffi based marshaller to libgobject This code is from https://bugzilla.gnome.org/show_bug.cgi?id=567087 and was adapted by myself to also support the GVariant fundamental type. Signed-off-by: David Zeuthen <davidz@redhat.com>