A Mutex is not reentrant. This deadlocks: m = Mutex.new m.lock m.synchronize {} So does this: m = Mutex.new m.synchronize {m.synchronize {}} But Monitor is reentrant, so the following does not deadlo...vjoel (Joel VanderWerf)
As noted at https://github.com/ruby/ruby/pull/451#issuecomment-28741490: These benchmarks miss the point of using rbtree, which is to pay a small insertion cost to keep the structure sorted so that ordered lookups are fast. If you onl...vjoel (Joel VanderWerf)
Another argument against `#identity`: it is used by several libraries for something completely different. For example, in narray: ~~~ruby >> NMatrix.float(2,2).identity => NMatrixfloat2,2: [ [ 1.0, 0.0 ], [ 0.0, 1.0 ] ] ~~~ ...vjoel (Joel VanderWerf)
=begin Requiring a gem with a C extension seems to be not threadsafe. Any one of the require lines below will frequently (but not always) cause an error like the following: /usr/local/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/k...vjoel (Joel VanderWerf)
You are right: it is best to leave these extensions out of trunk. I can maintain them separately. However, some clarifications: * the proposed #take_all and #replace_all operations do *not* block. They are like #read_all in that re...vjoel (Joel VanderWerf)
=begin = New primitives for Rinda::TupleSpace This issue proposes adding two new primitives to TupleSpace for atomic bulk operations: == 1. TupleSpace#replace_all === What it does Calling replace_all(tuple, new_tuple,...vjoel (Joel VanderWerf)
=begin Rinda::TupleSpaceProxy prevents tuple loss during #take by exposing a "port" object on the client that the remote side (the tuplespace server) pushes to, instead of relying on the method return value. Pushing to the port fails ...vjoel (Joel VanderWerf)
=begin The purpose of Rinda::TupleSpaceProxy is to avoid losing tuples when a client disconnects during a #take call. This is implemented by sending the result value ((*twice*)): first by pushing it to a client-side array, second by r...vjoel (Joel VanderWerf)