On 2 December 2010 03:38, Jon <jon.forums@gmail.com> wrote:

> Understood and I think your darwinistic focus is a good choice. If the mingw32 (fat or otherwise) binary is truly valued, patches should eventually flow, right? ;)

Thats the theory I'm working under.

>
> I see what you mean re: Function.c.  Doing a "gem install ffi --platform=ruby" using DevKit on 1.9.3dev errors out on 'async_cb_{mutex,cond,call,wait}' and then 'struct gvl_callback'.  I want to look into it.

It should be pretty straightforward to convert from pthread
conditionals and mutexes to the win32 equivalents.  The code isn't
doing a lot of tricky stuff, just putting stuff onto a queue,
signalling the queue processor and waiting for notification that the
task has completed.

>
> As your focus appears to be 1.9.2+, are you thinking that future mingw32 binary gems will _not_ be fat?

It would be 1.9.2+ only.  The main reason to ditch 1.8.x, is the lack
of threading support - specifically, the ability to detect non-ruby
threads trying to call back up into ruby, and handle that situation
sanely.  This causes all sorts of strange errors.  FFI should
technically build and work fine on 1.8.x apart from that.