Utilisation de hash non sécurisée par les threads dans Logster

Lors de l’utilisation de discourse dans une implémentation Ruby multithread et un serveur (TruffleRuby/Puma), des erreurs sont produites par l’utilisation non sécurisée des hash dans le gem logster près de cette section :

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

3 « J'aime »

Je vois, y a-t-il une chance que vous puissiez ajouter un Mutex là-bas dans une PR ? Cela semble être l’approche correcte pour résoudre ce problème.

(soit dit en passant @dev-managers / @jomaxro je suppose que pour être à parité avec d’autres projets, nous devrions garder les problèmes logster activés sur GitHub ? Mon vote est oui)

4 « J'aime »

Un message a été divisé en un nouveau sujet : Sur quels gems gérés par Discourse devrions-nous activer les problèmes GitHub

Si un Mutex est utilisé, il doit l’être à la fois pour les accès en écriture et en lecture pour garantir la correction.

Cette fonctionnalité semble mieux adaptée aux variables locales aux fibres/threads.
Est-il possible d’avoir plusieurs instances de Logster::Logger, ou y en a-t-il toujours une seule ? Si plusieurs, nous devons d’une manière ou d’une autre faire de l’object_id de l’instance une partie de la clé utilisée pour les recherches locales aux fibres/threads.

1 « J'aime »

Absolument ! Je pense que cela devrait résoudre le problème et simplifier considérablement ce code :+1:

2 « J'aime »

Je suis à peu près sûr qu’il n’y en a qu’une, mais j’ai ajouté quelques protections.

J’ai choisi de ne pas utiliser de define_finalizer, les consommateurs sont responsables du nettoyage, sinon la comptabilité devient très compliquée.

Ce sujet a été automatiquement fermé après 3 jours. Les nouvelles réponses ne sont plus autorisées.