Robert Klemme wrote:
> On 11.06.2007 16:21, Alex Young wrote:
>> At the risk of asking an FAQ, I've run into the following problem:
>>
>> irb(main):001:0> require 'thread'
>> => true
>> irb(main):002:0> class Mutex; attr_accessor :owner; end
>> => nil
>> irb(main):003:0> require 'rubygems'
>> => true
>> irb(main):004:0> require 'fastthread'
>> => true
>> irb(main):005:0> a = Mutex.new
>> => #<Mutex:0xb788184c>
>> irb(main):006:0> a.owner = :foo
>> NoMethodError: undefined method `owner=' for #<Mutex:0xb788184c>
>>         from (irb):6
>>
>>
>> As you can see, the method definition prior to the fastthread require 
>> is lost.  This wasn't a problem with 0.6.4, but is a problem with 
>> 1.0.  Is this a genuine bug, or is there a good reason for this?
> 
> I don't know.  But IMHO it's a bad idea to change class Mutex.  Why do 
> you think you need that?
It's in some legacy code that broke on a gem update.  It's used for 
logging which thread's currently got the lock from inside a #synchronize 
block.  I've fixed it by changing the require order, which I don't like 
much.  It could probably be refactored out, but that's not the point...

-- 
Alex