Merging the `thread_safe` gem

[jdantonio]

When this gem was first given to us the plan was to merge the code into concurrent-ruby and deprecate this gem. We chose to focus on atomic first and have now had two releases with the merged code. We're now discussing the final deprecation of atomic. Now is a good time to turn our attention to thread_safe. Before we start the work there are a couple of things we should discuss. In no particular order:

• We should probably issue one final release of thread_safe with a deprecation warning. This will allow current users to keep using the gem if they don't want to switch to concurrent-ruby (Rails, for example).
• Everything in concurrent-ruby exists under the Concurrent namespace. When we merge we should change the namespacing but provide backward-compatible aliases to ease migration. We did this with atomic.
• This gem uses minitest but concurrent-ruby uses rspec. We updated all the atomic tests to use rspec and probably should do that for this gem.
• In concurrent-ruby we have committed to providing pure-Ruby implementations of all abstractions so that we can be compatible with the widest range of Ruby interpreters. For ThreadSafe::Array and ThreadSafe::Hash this gem defaults to MRI's native array and has implementations. For consistency we should create pure Ruby versions.
• We should also consider whether the aforementioned use of MRI's array and hash classes are reliable. MRI does not have a published memory model and makes no guarantees regarding concurrency. As the code comment states, "should usually work fine." But that isn't a guarantee. For consistency with concurrent-ruby we may want to reconsider.
• Since concurrent-ruby now has a companion gem for C extensions we should also consider creating a C variant of the Java extension.

Depending on how quickly we make these decisions and move forward with the work we could potentially have the initial implementation available for the 0.9.0 release.

The previous discussion of this merge can be found here.

Thoughts?

@pitr-ch @mighe @chrisseaton @obrok @lucasallan @colinsurprenant @headius @thedarkone

[headius]

I have not followed how the concurrent-ruby gem has been broken into component pieces. If I understand right, there could be a concurrent-ruby-collections subgem that e.g. Rails could depend on, right?

Rest of the migration sounds right to me.

[jdantonio]

@headius Not sub-gems, sub-components. The concurrent-ruby gem is internally subdivided into groups so that a user can choose to load only a subset of the code, similar to what Active Support does (I can choose to require just active_support/core_ext rather than the whole gem). But concurrent-ruby still exists as only one gem (only the C-native extensions are in a separate gem). So Rails would still need to add the full concurrent-ruby gem as a dependency but could choose to load only a subset of the code.

Merging the code from thread_safe into concurrent-ruby doesn't mean that thread_safe has to go away. We can issue a "final release" like what we're doing with atomic. Rails could still use the last release of thread_safe and new development would occur in concurrent-ruby.

Another option is to keep thread_safe a separate gem but begin planning a new major release. This is what we are doing with the ref gem.

[headius]

Ok I see. It would be great if we could get Rails 5+ to start depending on concurrent-ruby right now, so they can kick the tires and have all the other goodies available. I'm not sure who to talk to about that.

I have no objections to the merge, but I want to hear from @thedarkone since he did a lot of work on thread_safe.

[thedarkone]

We should probably issue one final release of thread_safe with a deprecation warning.

If this is "prints something out" deprecation message, then care must be taken that this is a never bundler-installable on an any Rails version (Rails uses ~> 0.1 for 4.0 <-> 4.1 and ~> 0.3, >= 0.3.4 for 4.2+), so this would have to be a 1.0 release.

We should also consider whether the aforementioned use of MRI's array and hash classes are reliable.

They should be:

1. any "interesting/dangerous" code (insertion/deletion/resizing etc) of Array/Hash is pure C,
2. GVL is always held while running C code

=>

1. it shouldn't be possible to corrupt Array/Hash internals from pure Ruby code,
2. MRI does use real threads, but GVL is implemented as a native mutex, so releasing and acquiring it guarantees full memory visibility effects

Since concurrent-ruby now has a companion gem for C extensions we should also consider creating a C variant of the Java extension.

TS::Cache, TS::Array and TS::Hash implementations for MRI rely on GVL (+ 100% C-implemented Array/Hash) and are thus basically pretty much as efficient as it gets.

What would be the plan for native java implementation of TS::Cache?

It would be great if we could get Rails 5+ to start depending on concurrent-ruby.

Switching Rails' dependency from thread_safe to concurrent-ruby is possible, as long as

• this doesn't add any more transitive gem dependencies,
• concurrent-ruby is pure Ruby (no C exts),
• concurrent-ruby doesn't require/load anything by default (memory/boot speed related).

AFAIK all these conditions are met, right?

[headius]

I didn't know about the C ext limitation. That does indeed complicate
things, because concurrent - ruby now includes atomic, which uses C to do
atomicity on MRI.

[jdantonio]

• concurrent-ruby is pure-Ruby. The C extensions are isolated in the concurrent-ruby-ext gem which is entirely optional (as of the 0.8.0 release).
• concurrent-ruby does include a couple of "global" objects (thread pools. timer sets, etc.) but they are all lazy loaded. We wrap then in our Delay objects so they don't get initialized until used.
• With the final release of atomic (1.1.99) we added a post-install deprecation message but we certainly don't have to do that with thread_safe (and if it's an issue we can create another "final" release of atomic that removes the post-install message). Or we could make 1.0 the next release of thread_safe. I don't have a strong opinion either way.
• I haven't looked very deeply at the thread_safe yet so I don't have an answer regarding a Java implementation of TS::Cache, but we'll take a look.
• With the 0.8.0 release we added a dependency on the ref gem but, but the original author gave it to the ruby-concurrency organization. We're currently planning a 2.0 release. If having it as a transitive dependency is a problem for Rails we can merge some of the code into concurrent-ruby to handle that.

[headius]

@jdantonio Thanks for clarifying...now I think I understand the splitting of the gem. Full speed ahead!