While using discourse in a multi-threaded Ruby implementation and server (TruffleRuby/Puma), errors are produced by the unsafe hash usage in the logster gem near this section:
AI-generated summary
The discussion revolves around fixing the thread-unsafe hash usage in the Logster gem. bjfish reported errors caused by this issue in a multi-threaded Ruby environment. sam suggested adding a Mutex to fix the problem and eregon pointed out that a Mutex would need to be used on both write and read accesses for correctness.
sam created a pull request (#160) to simplify the code and address the issue using fiber/thread-local variables. In the pull request, he also added protections to handle multiple Logster::Logger instances, although he believes there is typically only one instance.
3 Likes
I see, any chance you can add a Mutex there in a PR? seems like the correct approach to fixing this.
(aside @dev-managers / @jomaxro I guess for parity with other projects we should keep logster issues enabled on github? my vote is yes)
4 Likes
A post was split to a new topic: On which Discourse managed gems should we enable GitHub issues
If a Mutex is used, it should be used on both the write and read accesses for correctness.
This functionality feels like a better fit for fiber/thread-local variables though.
Is it possible to have multiple Logster::Logger instances, or is it always just one? If multiple we somehow need to make the instance’s object_id part of the key used for fiber/thread-local lookups.
1 Like
Absolutely! I think this should fix it and heavily simplify this code at the same time 
2 Likes
Pretty sure there is only one, but I added some protections.
I opted out of using a define_finalizer consumers are responsible for clean up, otherwise the accounting gets very hairy.
This topic was automatically closed after 3 days. New replies are no longer allowed.