Hello,

I'm going to have to jump into this discussion as well. While I can't
get any hard statistic, I think I'm one of the largest users of FFI,
with the development of Vagrant, virtualbox bindings, and libvirt
bindings. All the aforementioned projects are used in "enterprisey"
environments, where the only company-bestowed Ruby installation is
that which their current OS ships with its package manager.

For Ubuntu users, this means that my corporate users are restricted to
Ruby 1.8.7 for another year at least (until another LTS release is
out). To support this, I've had to restrict FFI versions for my gems
to "~> 0.6.3" I'm even currently struggling with a company interested
in using my libvirt bindings, but they're restricting to Ruby 1.8.5!
(RedHat Enterprise Linux 5) While I think thats a bit too far back, I
think you get the idea.

While I agree that Ruby 1.9.x adoption is improving and moving
forward, there are important groups of people who simply _cant_ move
forward, even if they wanted to, due to corporate policy.

FFI is an important enough library for Ruby that this needs to be
handled in a cleaner way.

I'd love to help in any way I can. I've never written a C extension so
my experience falls short there, but if I can provide testing (Vagrant/
virtualbox _really_ stress FFI) or some other form of support, I'm
happy to.

Thanks for all your hard work so far.

Best,
Mitchell

On Dec 22, 11:24 am, Evan Phoenix <e...@fallingsnow.net> wrote:

> On Dec 22, 2010, at 11:16 AM, Charles Oliver Nutter wrote:
>
>
>
>
>
>
>
>
>

> > On Fri, Dec 3, 2010 at 4:57 AM, Wayne Meissner <wmeiss...@gmail.com> wrote:

> >>> If FFI is aiming 1.9.2 or bigger, then the rubygem spec needs to be
> >>> tweaked to reflect that. I'm not against of ditching 1.8.x support,
> >>> but just want to reduce painful support issues for users still using
> >>> 1.8.x

>

> >> Agreed, and I just pushed a change the restricts it to >= 1.9.2

>

> >> I'm not against it still working on 1.8.7 - I'm just against:

>

> >> a) doing the work to make it work, and
> >> b) dealing with issues when people try to run code that either
> >> requires blocking threads, or non-ruby threads calling back into ruby.

>

> > I think it's premature to drop 1.8.7 support. The majority of Ruby
> > users are still on 1.8.7, and that's not changing rapidly. There's
> > also people with production apps and released libraries that depend on
> > FFI.

>

> > I think we need to find a way to get support back in there ASAP.
> > Perhaps that means we need to actively find someone to help Wayne
> > maintain the FFI gem (or take over 1.8 support completely). If we
> > don't have FFI for 1.8.7, it becomes substantially less useful as a
> > cross-impl replacement for extensions.

>
> I agree. Sorry that I didn't chime in when 1.0.0 was released also, I got tied up with the Rubinius 1.2 release.
>
>
>

> > I appreciate the issues with blocking threads, but I think that's a
> > peril for any C extension on 1.8.7. In other words...we punt, since
> > there's no solution, and recommend people consider blocking calls when
> > using libraries through FFI.

>
> I agree this, is a tricky problem that Wayne has done a great job supporting. But I think that the difficulty in it points that it's just not possible to do properly with the architecture of 1.8. Not supporting callbacks on non-ruby threads seems like an OK compromise. Are there a lot of people using this functionality?
>
>
>

> > Wayne: Can you summarize what's needed to get 1.8.7 support back in the gem?

>
> Wayne, in the past we've talked about me help with the gem development and API. I'm happy to start doing this in earnest.
>
>
>
>
>
>
>
>
>

> > - Charlie