Drop Delay from global config

[jdantonio]

One of the biggest barriers to using autoload w/i this gem is the circular reference caused by the use of Delay within the global config. I no longer feel that we need to use Delay in the global config and I would like to remove it. I'd like some feedback from the community on this.

A bit of history...

The earliest versions of our thread pools spawned threads on construction. This meant that applications using c-r would always spawn a few background threads, even when they never post jobs (Rails and Sidekiq are good examples). To prevent this I used Delay to lazy-load the thread pools. This added a slight performance hit every time a job was post to a global thread pool because Delay objects are synchronized, but that seemed like a fair price to pay.

Later I decided to make the global thread pools configurable. This eventually lead us to add a reconfigure option on Delay. This, in turn, lead to the addition of a timeout option on Delay's #value call. To be consistent with everything else in this gem, Delay was updated to use the common executor options helper and default to a global thread pool. Hence, the circular reference.

Two things have changed since then that completely change the nature of this problem:

1. Our thread pools now lazy-load threads so no threads are created until the first job is post
2. We've removed the ability for the user to change the global thread pools (preferring dependency injection on the individual classes)

Subsequently, the use of Delay in the global config seems to provide little value. I think it can safely be removed. Removing it should give a tiny performance improvement every time a job is post to a global thread pool. More importantly, I can remove the circular reference that's been plaguing me.

Thoughts?

[pitr-ch]

Great sum-up. I am for removing it. It makes perfect sense. If we decide to migrate to autoload we can use it to load the thread pool instance lazily as well (they would be stored in a constant then) without paying the performance hit on access.

[jdantonio]

I quickly attempted this in PR #465 and many tests failed. It's not something I'm going to attempt right now, with the 1.0 release being so close. We'll make this part of the 2.0 release.

[eregon]

Just for info, autoload is also still unsafe on many implementations, so I would not recommend it for concurrent-ruby.

[pitr-ch]

@eregon Thanks for warning, do you know which ones? I thought it was fixed on MRI and JRuby.

[eregon]

Well, recent MRI has a couple autoloading bugs, there is a RubySpec which fails sporadically for years, a few bug/deadlock reports for JRuby, JRuby+Truffle and new implementations most likely do not handle it too well, etc.

[pitr-ch]

Ah ok, better not to use it then. I thought MRI and JRuby is ok, so we would just fix JRuby+Truffle.

[jdantonio]

I was under the impression, from a prior discussion with @headius, that autoload was thread safe on both MRI and JRuby. Both the atomic and thread_safe gems used autoload extensively, and both have been merged into c-r.

[eregon]

I solved some of the cycles for #934, but this specific cycle remains.
Yeah, it sounds like we should avoid using Delay there, seems pretty straightforward.

I would avoid using autoload for anything, there seems to be no need now that we have fine-grained dependencies between files.