Subject:
[ruby-ffi] Re: XNI and FFI summary?
From:
Wayne Meissner
Date:
3/5/13 12:02 AM
To:
ruby-ffi@googlegroups.com

On Tuesday, 5 March 2013 05:12:14 UTC+10, Jon wrote:

When you get a free moment, please provide a quick summary of:

  * XNI's main reason(s) for being

At the moment, its an experiment in native interface design.  The aim is a stream-lined FFI+ffi-compiler combo, with some hard-coded conventions to make it easier to implement common patterns when writing extensions, whilst avoiding the "gigantic-ball-of-mud" that is the ruby C api.  But, XNI does not try to do everything - since you don't get access to Ruby VM internals, you wouldn't use it for e.g. implementing a new data structure.

This is Jeremy's hitimes gem converted to use FFI+ffi-compiler:
https://github.com/wmeissner/hitimes/commit/b226af0498127a9e25f002b01db9230f68f93f7b

and converted to use XNI:
https://github.com/wmeissner/hitimes/commit/9252959cebc6678a969ba672438ba4b11ff98ef5

The XNI one has a bit less ruby boilerplate (XNI has the concept of a DataObject, which can have instance methods that automagically pass in 'self' to native methods).  On the other hand, XNI excises a few FFI concepts - there is no Struct that you can wrap around existing native memory, nor MemoryPointer for generic native memory allocations.

(as to why I used hitimes - its a fairly nicely written cext, it doesn't do anything super-complicated, but would be hard to implement in pure FFI due to the data structures and API calls it needs).

  * when should one prefer XNI over FFI?

That's a really good question - "when you're unhappy with FFI+ffi-compiler" would be the pithy answer.  FFI isn't going away, so if people are happy with it, then I encourage them to keep using it.  At this point, FFI is stable and works.  On the other hand, if you're writing a gem from scratch, and you're going to end up writing a bunch of ruby boilerplate around a raw FFI api, and you'll need to use ffi-compiler to compile some native shims, then XNI might be worth a look.  At least once it is a bit more stable.


  * will XNI always utilize FFI?

It will always utilize a ffi-like way of interfacing between the ruby VM and the native code (that is part of the design), but it won't always use the FFI gem.  There is a native backend for JRuby-1.7+, and I am currently working on a native CRuby backend.  There could also be a native backend for Topaz that uses ctypes (or whatever the RPython equivalent is).
 

Thanks.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

--
 
---
You received this message because you are subscribed to the Google Groups "ruby-ffi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-ffi+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.