As Matthew points out in his answer, it may be a plug-in that is causing this. He found that attachment_fu is one cause. (It can use Core Image for its image processing.) Creating a file in config/initializers
(for a Rails application) with this line will silence the warning, at the expense of requiring one of the other image processors:
Technoweenie::AttachmentFu.default_processors.delete('CoreImage')
This isn't a problem for me; I deploy to non-Mac servers, and since those can't use CoreImage, I want to run the same thing during development anyway.
If you look at /System/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/
objc/ruby_addition.rb
, this is at the bottom of the file:
class Thread
class << self
alias :pre_rubycocoa_new :new
# Override Thread.new to prevent threads being created if there isn't
# runtime support for it
def new(*args,&block)
unless defined? @_rubycocoa_threads_allowed then
# If user has explicilty disabled thread support, also disable the
# check (for debugging/testing only)
@_rubycocoa_threads_allowed = ENV['RUBYCOCOA_THREAD_HOOK_DISABLE'] ||
OSX::RBRuntime.isRubyThreadingSupported?
end
if !@_rubycocoa_threads_allowed then
warn "#{caller[0]}: Ruby threads cannot be used in RubyCocoa without patches to the Ruby interpreter"
end
pre_rubycocoa_new(*args,&block)
end
end
end
So for starters, we get a warning, but then it proceeds to call the original Thread.new
anyway. I don't believe this warning is a real problem. It's just annoying to see it constantly in the console.
If you want to track down what's pulling in the monkey patch to Thread
, grep for something that pulls in osx/cocoa
:
$ irb
>> Thread.new { puts 'hi' }
hi=> #<Thread:0x1011328e0 run>
>> require 'osx/cocoa'
=> true
>> Thread.new { puts 'hi' }
(irb):3:in `irb_binding': Ruby threads cannot be used in RubyCocoa without patches to the Ruby interpreter
hi=> #<Thread:0x103bf76e8 run>