CSC/ECE 517 Fall 2013/ch1 1w21 w: Difference between revisions
| Line 22: | Line 22: | ||
==How does it work?== | ==How does it work?== | ||
One of the largest problems plaguing Ruby implementations [..] is the ever-painful story of "extensions". In general, these take the form of a dynamic library, usually written in C, that plugs into and calls Ruby's native API as exposed through ruby.h and libruby. | //One of the largest problems plaguing Ruby implementations [..] is the ever-painful story of "extensions". In general, these take the form of a dynamic library, usually written in C, that plugs into and calls Ruby's native API as exposed through ruby.h and libruby. | ||
--Charles Nutter, of the core JRuby team | --Charles Nutter, of the core JRuby team// | ||
The many compiled bridges between external libraries and Ruby pose a problem for alternate implementations like JRuby, because of the complexity involved in exposing internals of the implementation or expensive serialization in both directions. Instead, an interface is necessary so that instead of developing libraries that act only as unique bridges to others, we can just have one library that provides the interface to any arbitrary library of our choice. | The many compiled bridges between external libraries and Ruby pose a problem for alternate implementations like JRuby, because of the complexity involved in exposing internals of the implementation or expensive serialization in both directions. Instead, an interface is necessary so that instead of developing libraries that act only as unique bridges to others, we can just have one library that provides the interface to any arbitrary library of our choice. | ||
Revision as of 17:47, 18 September 2013
CSC/ECE 517 Fall 2013/ch1 1w21 w
Ruby libraries to load objects of other languages at run time
This is an advanced topic. Libraries are being developed where Ruby gems can load libraries (and even native code) of other languages.A few open-source projects like FFI are currently working on this.
Introduction
Runtime Library
In computer programming, a runtime library is the API used by a compiler to invoke some of the behaviors of a runtime system. The runtime system implements the execution model and other fundamental behaviors of a programming language. The compiler inserts calls to the runtime library into the executable binary. During execution (run time) of that computer program, execution of those calls to the runtime library cause communication between the application and the runtime system. This often includes functions for input and output, or for memory management. The runtime library may implement a portion of the runtime system's behavior, but if one reads the code of the calls available, they typically are thin wrappers that simply package information and send it to the runtime system. However, sometimes the term runtime library is meant to include the code of the runtime system itself, even though much of that code cannot be directly reached via a library call.
For example, some language features that can be performed only (or are more efficient or accurate) at runtime are implemented in the runtime system and may be invoked via the runtime library API, e.g. some logic errors, array bounds checking, dynamic type checking, exception handling and possibly debugging functionality. For this reason, some programming bugs are not discovered until the program is tested in a "live" environment with real data, despite sophisticated compile-time checking and pre-release testing. In this case, the end user may encounter a runtime error message.
The concept of a runtime library should not be confused with an ordinary program library like that created by an application programmer or delivered by a third party, nor with a dynamic library, meaning a program library linked at run time.
libffi
FFI stands for Foreign Function Interface. A foreign function interface is the popular name for the interface that allows code written in one language to call code written in another language. The libffi library really only provides the lowest, machine dependent layer of a fully featured foreign function interface. A layer must exist above libffi that handles type conversions for values passed between the two languages.[1] libffi is a foreign function interface library. It provides a C programming language interface for calling natively compiled functions given information about the target function at run time instead of compile time. It also implements the opposite functionality: libffi can produce a pointer to a function that can accept and decode any combination of arguments defined at run time. libffi is most often used as a bridging technology between compiled and interpreted language implementations. libffi may also be used to implement plug-ins, where the plug-in's function signatures are not known at the time of creating the host application. Notable users include Python, Haskell, Dalvik, F-Script, PyPy, PyObjC, RubyCocoa, JRuby, Rubinius, MacRuby, gcj, GNU Smalltalk, IcedTea, Cycript, Pawn, Squeak, Java Native Access, Racket,[2] Embeddable Common Lisp and Mozilla.[3] On Mac OS X libffi is commonly used with BridgeSupport, which provides programming language neutral descriptions of framework interfaces, and Nu which binds direct Objective-C access from Lisp. libffi has been widely ported and is released under a MIT license.
How does it work?
//One of the largest problems plaguing Ruby implementations [..] is the ever-painful story of "extensions". In general, these take the form of a dynamic library, usually written in C, that plugs into and calls Ruby's native API as exposed through ruby.h and libruby.
--Charles Nutter, of the core JRuby team//
The many compiled bridges between external libraries and Ruby pose a problem for alternate implementations like JRuby, because of the complexity involved in exposing internals of the implementation or expensive serialization in both directions. Instead, an interface is necessary so that instead of developing libraries that act only as unique bridges to others, we can just have one library that provides the interface to any arbitrary library of our choice.
Ruby already has a library called "dl" that makes it possible to dynamically link external libraries with Ruby. It's a bit arcane though, and Charles points out that it's not widely used "because of real or perceived bugs." Given this, and given the need for an implementation that can be compatible with JRuby, Wayne Meissner has developed "FFI", a new Ruby library that provides "Foreign Function Interface" features to Ruby.
A basic demonstration of a Ruby script that uses C's getpid function should be enough to demonstrate the simplicity of FFI: code require 'ffi'
module GetPid
extend FFI::Library attach_function :getpid, [], :uint
end
puts GetPid.getpid code
Who uses it?
The libffi library is useful to anyone trying to build a bridge between interpreted and natively compiled code. Some notable users include: CPython - the default, most-widely used implementation of the Python programming language uses libffi in the standard ctypes library. OpenJDK - the open-source implementation of the Java Platform Standard Edition uses libffi to bridge between the interpreter and native code for some platforms. js-ctypes - a foreign function interface for javascript that Mozilla will be shipping in Firefox 3.6. Dalvik - Dalvik is the virtual machine which runs the Java platform on Android mobile devices. libffi is used on Android ports for which no custom bridging code has been written. Java Native Access (JNA) - the JNI-free way to call native code from Java. Ruby-FFI - a Foreign Function Interface extension for Ruby. fsbv - Foreign Structure By Value is a foreign function interface library for Common Lisp that extends the standard CFFI package to include support for passing structure arguments by value. JSCocoa - call Objective-C code from javascript on Mac OSX and the iPhone (via the libffi-iphone port). PyObjC - call Objective-C code from Python on Mac OSX. RubyCocoa - call Objective-C code from Ruby on Mac OSX. PLT Scheme - call C code from this popular Scheme implementation (also used as the implementation platform for Paul Graham's new Lisp, Arc). gcj - the runtime library for the GNU Compiler for the Java Programming Language uses libffi to handle calls back and forth between interpreted and natively compiled code. gcj is part of the GCC, the GNU Compiler Collection.
Supported Platforms
Libffi has been ported to many different platforms. For specific configuration details and testing status, please refer to the wiki page [1] here]
Authors and Credits
libffi was originally written by Anthony Green The developers of the GNU Compiler Collection project have made innumerable valuable contributions. See this ChangeLog files in the source distribution for details.
Some of the ideas behind libffi were inspired by Gianni Mariani's free gencall library for Silicon Graphics machines.
The closure mechanism was designed and implemented by Kresten Krab Thorup.
Major processor architecture ports were contributed by the following developers:
aarch64 Marcus Shawcroft, James Greenhalgh alpha Richard Henderson arm Raffaele Sena blackfin Alexandre Keunecke I. de Mendonca cris Simon Posnjak, Hans-Peter Nilsson frv Anthony Green ia64 Hans Boehm m32r Kazuhiro Inaoka m68k Andreas Schwab microblaze Nathan Rossi mips Anthony Green, Casey Marshall mips64 David Daney moxie Anthony Green pa Randolph Chung, Dave Anglin, Andreas Tobler powerpc Geoffrey Keating, Andreas Tobler, David Edelsohn, John Hornkvist powerpc64 Jakub Jelinek s390 Gerhard Tonn, Ulrich Weigand sh Kaz Kojima sh64 Kaz Kojima sparc Anthony Green, Gordon Irlam tile-gx/tilepro Walter Lee x86 Anthony Green, Jon Beniston x86-64 Bo Thorsen xtensa Chris Zankel
Adoption