Uso inseguro de hash en Logster en hilos

Al usar discourse en una implementación y servidor Ruby multihilo (TruffleRuby/Puma), se producen errores debido al uso inseguro de hash en la gema logster cerca de esta sección:

https://github.com/discourse/logster/blob/31849a4154c6b1edb05fe6d241076329aa228359/lib/logster/logger.rb#L23-L29

3 Me gusta

Entendido, ¿hay alguna posibilidad de que agregues un Mutex allí en un PR? Parece el enfoque correcto para solucionarlo.

(aparte @dev-managers / @jomaxro supongo que para mantener la paridad con otros proyectos deberíamos mantener los problemas de logster habilitados en github? mi voto es sí)

4 Me gusta

Se dividió una publicación en un nuevo tema: En qué gemas administradas por Discourse deberíamos habilitar los problemas de GitHub

Si se utiliza un Mutex, debe usarse tanto en los accesos de escritura como en los de lectura para que sea correcto.

Esta funcionalidad parece encajar mejor con las variables locales de fibra/hilo.
¿Es posible tener múltiples instancias de Logster::Logger, o siempre es solo una? Si son múltiples, de alguna manera necesitamos hacer que el object_id de la instancia sea parte de la clave utilizada para las búsquedas locales de fibra/hilo.

1 me gusta

¡Absolutamente! Creo que esto debería solucionarlo y simplificar enormemente este código :+1:

2 Me gusta

Bastante seguro de que solo hay una, pero agregué algunas protecciones.

Opté por no usar un define_finalizer, los consumidores son responsables de la limpieza, de lo contrario, la contabilidad se vuelve muy complicada.

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