Just thought I'd let people know about a project I've been tinkering
with - XNI - https://github.com/wmeissner/xni
XNI is an attempt to provide a good ruby <-> C/C++ api for JRuby,
without the problems of the legacy MRI cext interface, nor having to
write extensions directly in JNI.
The basic goals I had are:
1) JRuby is the primary Ruby VM target, but extensions should also run
without modification on MRI. Performance will be excellent on JRuby,
thanks to invokedynamic. MRI is currently somewhat slower than a cext
at this stage (but that can be cured with a sufficient application of
force). Really, if you're using MRI for performance, you're doing it
wrong. XNI extensions are even _binary_ compatible between JRuby and
MRI - especially helpful if you need to support win32/win64.
2) No ruby object access from C/C++ - people invariably get this
wrong, and implementing it in a solid, cross-vm way is quite
difficult.
This means there is a simplified data passing protocol - XNI is
symmetric (if XNI allocates it, only XNI can free it - if C/C++
allocates it, C/C++ code must free it), and method parameter and
result types are restricted to simple, well defined types - i.e. no
generic VALUE params where the C code then needs to extract data from.
Data is copy in/copy out - and native objects cannot be returned from
native code, nor can ruby objects be retained in native code - so no
ownership issues.
3) Convention over configuration where sensible.
e.g. for a module Example, with a class Foo (i.e. Example::Foo):
- data structures are named Example_Foo
- instance functions are example_foo_<method name>
4) MultiVM support - if you have multiple JRuby VM instances within
the one JVM, there should be no problems with loading the same XNI
extension in each ruby VM.
5) Resolve some of the problems with FFI (difficult to map complex
data structures, no access to C macros). XNI has the API declared in
ruby, and generates C function prototypes and data structures from
that definition. You then implement those functions in C/C++. Data
can be either exposed to ruby (where you want to share values directly
between ruby and C/C++), or opaque (where the data is only accessed
from C/C++, but is still associated with a ruby object).
XNI is currently experimental, so its good for people that want to
kick the tyres and hack, but not if you want to release a
production-ready gem based on it.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
