Lock Error when nesting ThreadSafe::Cache objects

[soupmatt]

I see that you cannot nest the usage of ThreadSafe::Cache objects in version 0.3.5 of the gem because there is a single Mutex for all instances of ThreadSafe::Cache. Looking through the git history, I see that this issue has existed since at least 2012, so if you guys don't want to fix it, that makes total sense to me.

Here's a little ruby script that demonstrates the issue.

require 'thread_safe'

outer = ThreadSafe::Cache.new
inner = ThreadSafe::Cache.new

outer.compute("seven") do
  three = inner.compute("three") { 3 } #blows up here
  three + 4
end

The place where the issue comes in for me is with using Rails.cache in conjunction with a ThreadSafe::Cache as the ActiveSupport::Cache seems to use one already under the hood. I'm using Rails v4.2.

I'm planning on switching to Concurrent::Map once I upgrade my project from concurrent-ruby 0.9.2 to 1.0.0 and I can monkey patch until then.

[jdantonio]

I'm have mixed feelings. We've fixed this in concurrent-ruby so I's rather not release updates to thread_safe. OTOH since Rails 4 uses thread_safe we need to support it until most shops have updated to Rails 5--and that's going to take a long time.

If you don't mind using your monkey patch solution for now then I'd rather not release an update to thread_safe. But I'm happy to keep this issue open indefinitely. If other users start having trouble with this we can release an update later.

Will that work for you?

[soupmatt]

That works for me. Thanks for the quick reply. :)

On Mon, Jan 25, 2016 at 11:21 AM jdantonio notifications@github.com wrote:

I'm have mixed feelings. We've fixed this
https://github.com/ruby-concurrency/concurrent-ruby/blob/master/lib/concurrent/collection/map/mri_map_backend.rb#L14
in concurrent-ruby so I's rather not release updates to thread_safe. OTOH
since Rails 4 uses thread_safe we need to support it until most shops have
updated to Rails 5--and that's going to take a long time.

If you don't mind using your monkey patch solution for now then I'd rather
not release an update to thread_safe. But I'm happy to keep this issue open
indefinitely. If other users start having trouble with this we can release
an update later.

Will that work for you?

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[jdantonio]

:-)