マルチスレッドのRuby実装とサーバー（TruffleRuby/Puma）でDiscourseを使用していると、フラグ設定におけるハッシュの安全でない使用によってエラーが発生します。この遅延初期化パターンでは、二重代入を回避する必要があります。
「いいね！」 3
イニシャライザで PostActionType.flag_settings を単純に呼び出すだけで問題は解決しますか？（例：一時的にここに挿入するだけです: discourse/config/initializers/000-mini_sql.rb at 3e0cb8ea47ea27cb3b564ac10656884739e4d78c · discourse/discourse · GitHub
このブロックも同期できると思います。他に truffle が警告している大きな問題はありますか？
「いいね！」 2
はい、それでうまくいくはずです。
これを遅延初期化する理由は何でしょうか？
早期に初期化すれば、同期の問題を回避でき、アクセスもわずかに速くなり、よりシンプルになります。
「いいね！」 1
率直に言って、この遅延初期化がここで意味をなすのかどうかはわかりません。プラグインがフラグのセット全体を置き換えるためのフックがありますが、それは初期化子よりも前に発生します。
@roman、ここで早期初期化について懸念はありますか？簡単な修正は次のとおりだと思います。
class << self
def flag_settings
...
end
end
flag_settings
これが起こった主な理由は、Ruby がクラス初期化子のクリーンなパターンを出荷していないため、開発者は独自のパターンを発明したり、遅延を使用したりすることになるのだと思います。
「いいね！」 2
このようにすることも可能で、これにより ivar を 2 回読み取ることを回避し、早期初期化であることがより明確になります（整理のために、ロジックを initial_flag_settings ヘルパーメソッドに含めることももちろん可能です）。
class << self
attr_reader :flag_settings
end
@flag_settings = FlagSettings.new
@flag_settings.add(
3,
:off_topic,
notify_type: true,
auto_action_type: true,
)
# ...
「いいね！」 2
はい、ここでは早期初期化で問題ないと思います。また、めったに使用されないプラグインAPIとも競合しないはずです。
「いいね！」 3
PRはこちらです。
「いいね！」 4
このトピックは4日後に自動的に閉じられました。新しい返信は許可されていません。