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 :
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)
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.
Absolument ! Je pense que cela devrait résoudre le problème et simplifier considérablement ce code ![]()
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.