rbx consumes 100% of CPU when use FFI

[testors]

sleep.c

#include <unistd.h>
#include <stdio.h>

void mysleep()
{
        while( 1 ) sleep( 1000 );
}

sleep.rb

require 'ffi'
require 'irb'

module MYFFI
  extend FFI::Library
  ffi_lib 'c'
  ffi_lib './libsleep.so'

  attach_function :mysleep, [], :void
end

Thread.new do
        MYFFI.mysleep()
end

IRB.start

How to reproduce :

$ gcc -c -fpic sleep.c
$ gcc -shared -o libsleep.so sleep.o
$ rbx -v
rubinius 2.5.2 (2.1.0 7a5b05b1 2015-01-30 3.5.1 JI) [x86_64-freebsd10.1]
$ rbx sleep.rb
(display nothing and rbx consumes 100% of CPU)

jruby works well.

$ jruby -v
jruby 1.7.15 (1.9.3p392) 2014-09-03 82b5cc3 on OpenJDK 64-Bit Server VM 1.7.0_80-b15 +jit [FreeBSD-amd64]
$ jruby sleep.rb
irb(main):001:0>

[brixen]

@testors are you using C-ext Readline or rb-readline?

[brixen]

@testors the behavior you are seeing results from two things, one I can change easily and one that takes a bit more work and thought: 1) we are stopping all threads to check if we should run the GC; and 2) the thread making an FFI call (ie calling into some sort of native code) is still marked as GC-dependent, so when it blocks, the whole process will block as soon as a GC is triggered.

The first one is easy to remove. A GC event is much less common than not, so we do a simple check and re-check after check-pointing. We check for a pending GC all the time, so a false negative has no bad consequence.

The second is more complicated because if we mark the thread executing an FFI call as GC-independent, we need to ensure that any re-entry to managed code marks the thread as GC-dependent (and possibly blocks waiting for an existing GC run to complete). A more complex issue is ensuring that no concurrent mutator or GC activity could invalidate any assumptions that may exist for the native code that is executing in the GC-independent thread.

[brixen]

Rubinius will continue to maintain compatibility with the current stable version of MRI to the extent possible.

The focus for Rubinius in the near term is on the following capabilities:

1. Instruction set
2. Debugger
3. Profiler
4. Just-in-time compiler
5. Concurrency
6. Garbage collector

Contributions in the form of PRs for any of the areas of focus above, or for Ruby compatibility, are appreciated.