On Fri, 2005-02-25 at 12:10 -0500, Owen Taylor wrote: >On Fri, 2005-02-25 at 11:08 -0500, John Ehresman wrote: >> Matthias Clasen wrote: >> > Is using libffi or something similar a problem ? >> >> I think we want to set things up so libffi could be easily used. In >> other words, the information that libffi needs should be easily >> obtainable from the introspection api. I'd also like not to have to >> wrap everything in GValue's if that can be avoided. That said, we need >> to figure out how to package libffi for non-gcc compilers such as MS VC++. > >libffi in my memory has a pretty horrid interface, and I think there >is some value in wrapping in something more GLibish. > >GValue has significant performance problems, I was not aware of this, and it's an unpleasant surprise to find it out, considering how GValue is used extensively in gtk+ (properties/signals). > but perhaps we could just >reuse it as a union and forget g_value_set_object() and friends for this >usage. On the other hand, that might be confusing, so maybe a separate >union structure (without the excessive space consumption of GValue) >would make sense. > >A wrapper also gives the ability to use something else internally - >perhaps the XptCall stuff from Mozilla which certainly works with >MSVC. Right. A XptCall/libffi kind of abstraction would be nice thing to have in glib ;-) > (I haven't really looked at the portability of libffi. The >libgcj version is mixed up with GCC extensions, but that may not >be fundamental to its operations.) > >My basic idea is that we'd provide something like: > > g_function_desc_invoke (GFunctionDesc *desc, > const GArgument *in_args, > int n_in_args, > const GArgument *out_args, > int n_out_args, > GArgument *return_value); > >Where GFunctionDesc is the API object for FunctionBlob. (I forget >what it was called in Matthias's writeup.) You'd also want the reverse >marshaling from C to GArgument. Right. That looks like an interesting API to use by bindings. Of course, I don't really know what GArgument contains... It worries me that we already have PyObject<->GValue conversion code in pygtk, but we'll have to create new conversion code for PyObjec<->GArgument. Are you sure GArgument is going to get us any performance improvement at all? If in doubt, I'd stick to GValue. Regards. -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature