Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove threadsafe gem dependency #45

Closed
wants to merge 2 commits into from

Conversation

@mperham
Copy link
Contributor

mperham commented Feb 3, 2016

This PR includes the whitespace PR I just sent. If you merge that PR, you should just see the relevant changes here.

This change removes the thread_safe gem dependency and instead uses a Mutex as a write barrier to ensure multiple threads can't write to the Hash at the same time.

mperham added 2 commits Feb 3, 2016
Since the countries and timezones hash are mostly read only, we can wrap the only write operation in a Mutex.
@matthewd
Copy link

matthewd commented Feb 3, 2016

(I believe) it's unsafe to read a hash at the same time it's being written -- it's not just writes that need the mutex.

cc @thedarkone

@philr
Copy link
Member

philr commented Feb 3, 2016

Thanks for submitting the PRs. I hadn't spotted that the thread_safe gem is being deprecated.

Is synchronizing just Hash write operations guaranteed to be safe on all Ruby implementations? ThreadSafe::Cache and the replacement Concurrent::Map use this approach for MRI, but have alternative implementations for JRuby, Rubinius, etc.

@mperham
Copy link
Contributor Author

mperham commented Feb 3, 2016

I wasn't sure if reading was an issue. The alternative is to pull in concurrent-ruby instead of thread_safe.

@philr
Copy link
Member

philr commented Feb 4, 2016

I'm happy with switching from thread_safe to concurrent-ruby.

tzinfo currently has a required_ruby_version of >= 1.8.7. This would need changing to >= 1.9.3 to match concurrent-ruby. Some of the code to support Ruby 1.8 in and around ruby_core_support.rb could also then be dropped.

@mperham
Copy link
Contributor Author

mperham commented Feb 4, 2016

@philr Yeah, you just need to move from ThreadSafe::Hash to Concurrent::Hash. Exact same semantics.

@mperham
Copy link
Contributor Author

mperham commented Feb 4, 2016

Feel free to close this and do that instead.

@thedarkone
Copy link

thedarkone commented Feb 4, 2016

@matthewd is right, technically it is not enough to have synchronization just on the write side. I will readily admit that right now, on all the current Ruby VMs, when run on x86 hardware, synchronization on the read side is not required, but I'm pretty sure that this is going to change on the new gen of runtimes (namely truffle+jruby).

@philr if swapping thread_safe for concurrent-ruby (concurrent-ruby is a larger code base) is not an issue, go for it. Concurrent::Map is a carbon copy of ThreadSafe::Cache.

PS: @matthewd, thx for the ping.

@philr
Copy link
Member

philr commented Feb 4, 2016

@thedarkone thanks for the confirmation regarding write-only synchronization.

The larger code base of concurrent-ruby is unlikely to be an issue. I think the majority of TZInfo users are using it through ActiveSupport and ActiveSupport has already switched to concurrent-ruby for the upcoming Rails 5 release.

I've raised #46 for switching to Concurrent::Map.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.