Drop Delay from global config

未关闭
#460 8 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

@eregon 已经在做这个了。

开始于 2023年1月23日。

评估

这个 Issue 还没有评估数据。

描述

enhancement looking-for-contributor

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?

主要语言
Ruby
星标
5.8k
派生
420
平均合并
20 小时 45 分钟
30 天内合并 PR
4

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

ruby-concurrency/concurrent-ruby 的其他 Issue

查看 ruby-concurrency/concurrent-ruby 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。