That broken rubyspec was written by me. The problem lies with repeatedly `autoload`ing the same `.rb` file, since this should be impossible, the spec manually deletes the loaded path from `$LOADED_FEATURES` and then re-declares the `auto...thedarkone (Vit Z)
Petr Chalupa wrote: > it certainly looks appealing and convenient to have atomic ivars, but I have an devil advocate's question. What are the advantages of having atomic_attr over just using `@a = Atomic.new('a_value')` with some conven...thedarkone (Vit Z)
Eric Wong wrote: > Does that mean segfaulting the VM on concurrent Hash or Array access > ... I agree with you :). Otherwise JRuby is implemented on top of JVM, which is supposed to be a safe language/VM, so one should never be ab...thedarkone (Vit Z)
Eric Wong wrote: > Right. There's no way I will ever advocate a memory barrier of any > ... My thesis and objection to adding "atomic" methods to `Array` or `Hash` is that it would necessarily entail making them thread-safe as a who...thedarkone (Vit Z)
> I do atomic operations all the time in C on arbitrary addresses. > ... Are you talking about Ruby with GVL or C in general? If C in general then I don't understand how barrier-less access to concurrently updatable data does not res...thedarkone (Vit Z)
In my opinion an ideal API would have "atomic" attributes declared at the class level, yet can be used as normal `@foo` i-vars: ~~~ class MyNode atomic :item, :successor
I'm not sure @matz/@ko1 understood what @postmodern was trying to describe. Given an `overlfow.rb` ruby program: ~~~ruby 200.times do |i| eval <<-RUBY_EVAL, nil, __FILE__, __LINE__ + 1 def foo_#{i}(&block) foo_#{i+1...thedarkone (Vit Z)
thedarkone (Vit Z)04:59 AM Ruby Bug #10892: Deadlock in autoload