00:37 <bazzy> what's up?

01:10 <bazzy> ---

01:10 <bazzy> I had something weird happen ... X_X .. still trying to understand it ..

01:12 <bazzy> it looks like 2 users in 2 different channels accidently exploited a race condition through a matcher function ... the handler's local variable (matched parameter) somehow made it into the other user's function .. so that user A's parameter became user B's even though processing logic had already been done in user A parameter XD

01:13 <bazzy> Has this kind of thing been reported before?

01:15 <bazzy> I see the problem .. there's an instance object that is being accessed by both threads (matchers) .. I wonder how to serialize access best?

01:28 <bazzy> ----

01:30 <bazzy> I've determined in the context of my plugin, it is best to serialize processing of the matchers completely .. not only to maintain data integrity but also because my plugin is a game where "out-of-order" thread processing would create an unfair state of play (I assume there is a risk of out-of-order processing with the threads.. but there is a chance this was "in-order, but read/writing shared memory at too close a time)

01:32 <bazzy> I am led to believe that using thread-matchers could create a non-FIFO situation .. and if so I need please pointers on making the Cinch matchers operate serially just for this plugin (although I'm impartially open to "global" serial fix)