--001517574716ee1b12047e0072fc
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 25, 2010 at 7:37 AM, Charles Oliver Nutter
<headius / headius.com>wrote:

> On Mon, Jan 25, 2010 at 6:29 AM, Aaron Patterson
> <aaron / tenderlovemaking.com> wrote:
> > I thought FFI was supposed to solve this problem.  Is it not?
>
> As Tony mentioned, it solves the problem just fine, except that you
> still have to have the right libraries available and permission to use
> them. Lots of production deployment environments for Java disallow
> loading native libraries because they have a much higher likelihood of
> crashing the JVM or circumventing its security policies. Google App
> Engine, for example, doesn't allow loading native libraries at all,
> and of course any small profile Java environments will often be unable
> to use native libs as well (like Android).
>

Charlie, you're making a great case against using FFI.

It sounds like you're recommending that gems containing non-ruby code, like
Nokogiri, need to be written twice: once in C, and once in Java. Is that an
accurate interpretation?

(Unless, of course, you take Eleanor's advice and do everything in pure
Ruby. Hello, REXML! :-D )


>
> > I implore Ruby implementors to support the MRI C api, as it too is part
> > of Ruby's api.  Think about who you hurt by not letting people reuse
> > valuable libraries written in C.  :-)
>
> The MRI C API is terrible if you want to implement it for anything
> other than MRI. It allows direct pointer access to object internals,
> allows you to *write* to objects directly in memory, has absolutely no
> consideration for concurrent execution, no abstraction around object
> locations in a relocating GC, and no methods or standards for handling
> reference lifecycle (that I am aware of). As I've stated before (and
> told you) we'd be happy to support a C API that did not include all
> the unsafe bits (like accessing array, string, or hash contents
> *directly*) and only allows you access to objects via a handle-based
> indirection mechanism. It's just a matter of time and effort to
> implement it...and there's a bounty to do so :)
>
> Even then, however, it still wouldn't solve the problems of loading
> native libraries on secure environments.
>
> I firmly believe the MRI's C API is the #1 thing holding it back. Why
> can't we get a better GC in place? Native extensions. Why can't we
> have real concurrent threading? Native extensions. Why is it a pain in
> the ass to use MRI on environments without a compiler easily
> available, like Windows? Native extensions. When used with plain Java
> libraries, JRuby works almost identically across all platforms without
> modification, without build tools present, and without segfaults. That
> beats supporting the current unsafe C API any day.
>
> - Charlie
>
>


-- 
mike dalessio
mike / csa.net

--001517574716ee1b12047e0072fc--