Inicialización perezosa no segura para hilos en PostActionType

Error
1

Al usar discourse en una implementación y servidor Ruby multihilo (TruffleRuby/Puma), se producen errores por el uso inseguro de hash en la configuración de banderas y este patrón de inicialización perezosa necesita evitar la asignación dos veces:

3 Me gusta
2

¿Una simple llamada a PostActionType.flag_settings en un inicializador resuelve el problema? (por ejemplo, solo insértalo aquí: discourse/config/initializers/000-mini_sql.rb at 3e0cb8ea47ea27cb3b564ac10656884739e4d78c · discourse/discourse · GitHub temporalmente)

Supongo que también podríamos sincronizar este bloque. ¿Hay alguna otra señal de alarma importante que truffle esté generando?

2 Me gusta
3

Sí, eso debería funcionar.
¿Hay alguna razón para inicializar esto de forma diferida?
Inicializarlo de forma anticipada evitaría cualquier problema de sincronización y sería un poco más rápido de acceder, además de más simple.

1 me gusta
4

Honestamente, no estoy seguro de si esta inicialización perezosa tiene sentido aquí también, tenemos un hook para que los plugins reemplacen todo el conjunto de flags, pero eso se activaría antes del inicializador.

@roman, ¿alguna preocupación con una inicialización ansiosa aquí? Supongo que la solución trivial es:

class << self

  def flag_settings
     ...
   end
end

flag_settings

Creo que la gran razón por la que esto sucedió es que Ruby no ofrece un patrón limpio para los inicializadores de clases, por lo que empuja a los desarrolladores a inventar los suyos propios/usar los perezosos.

2 Me gusta
5

También se podría hacer de esta manera, lo que evitaría notablemente leer el ivar dos veces y dejaría más claro que se inicializa de forma ansiosa (la lógica también podría estar en un método auxiliar initial_flag_settings para la organización, por supuesto):

  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 Me gusta
6

Sí, creo que la inicialización anticipada sería segura aquí. Tampoco debería entrar en conflicto con la API de complementos, que rara vez se utiliza.

3 Me gusta
7

Aquí tienes una PR:

4 Me gusta
8

Este tema se cerró automáticamente después de 4 días. Ya no se permiten nuevas respuestas.