PostActionType의 스레드 안전하지 않은 지연 초기화

기여 버그
1

멀티스레드 Ruby 구현 및 서버(TruffleRuby/Puma)에서 discourse를 사용할 때, 플래그 설정의 안전하지 않은 해시 사용으로 인해 오류가 발생합니다. 이러한 지연 초기화 패턴은 두 번의 할당을 피해야 합니다:

3개의 좋아요
2

initializer에서 PostActionType.flag_settings를 단순히 호출하는 것만으로 문제가 해결될까요? (예: 여기(discourse/config/initializers/000-mini_sql.rb at 3e0cb8ea47ea27cb3b564ac10656884739e4d78c · discourse/discourse · GitHub)에 임시로 삽입)

이 블록도 동기화할 수 있을 것 같습니다. truffle이 제기하는 다른 주요 경고 사항이 있나요?

2개의 좋아요
3

네, 그렇게 하면 작동할 것입니다.
이것을 지연 초기화(lazy initialization)해야 하는 이유가 있나요?
즉시 초기화(eager initialization)하면 동기화 문제를 피할 수 있을 뿐만 아니라, 접근 속도도 약간 더 빠르고 구현도 더 간단해집니다.

1개의 좋아요
4

솔직히 여기에서 게으른 초기화(lazy init)가 아예 의미가 있는지 확신이 서지 않습니다. 플러그인이 플래그 전체 세트를 교체할 수 있는 훅이 있지만, 그 훅은 초기화기(initializer)보다 먼저 실행됩니다.

@roman 여기서 즉시 초기화(eager init)하는 것에 대해 우려되는 점이 있나요? 아마도 가장 단순한 수정 방법은 다음과 같습니다:

class << self

  def flag_settings
     ...
   end 
end

flag_settings

이 문제가 발생한 큰 이유는 Ruby에 클래스 초기화기를 위한 깔끔한 패턴이 제공되지 않기 때문에, 개발자들이 자체적으로 패턴을 만들거나 게으른 초기화를 사용하도록 유도된다는 점이라고 생각합니다.

2개의 좋아요
5

다음과 같이 구현할 수도 있습니다. 이렇게 하면 인스턴스 변수를 두 번 읽는 문제를 피할 수 있고, 즉시 초기화(eager-initialized)되었음이 더 명확해집니다. (물론 코드 조직을 위해 로직을 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개의 좋아요
6

네, 여기서는 즉시 초기화(eager initializing)를 사용하는 것이 안전할 것 같습니다. 또한 거의 사용되지 않는 플러그인 API와도 충돌하지 않을 것입니다.

3개의 좋아요
7

PR가 있습니다:

4개의 좋아요
8

이 주제는 4일 후 자동으로 닫혔습니다. 더 이상 새 답변을 게시할 수 없습니다.