Closed carbolymer closed 1 year ago
OK. I understand. One approach to fix this is prepare a write queue and a writer thread for each buffer. Are there anything else?
@ruicc @khibino You might be interested in this issue. In short, atomicModifyRef'
is done in order but there is no guarantee to execute writeLogStr
in order.
Ordering is not a big problem for me because log services I'm using (e.g. datadog, bigquery) can handle it.
Synopsis
Due to check-then-act race condition and not enough synchronization in https://hackage.haskell.org/package/fast-logger-3.1.1/docs/src/System.Log.FastLogger.Logger.html#pushLog in
otherwise
case, if the log messages are shorter than buffer size and there are multiple threads logging messages at once using a single buffer, messages are not logged in order.Reproduction conditions
newFDLoggerSet
) with a single buffer (Just 1
) with a big buffer size. Default 4096 should be enough.t
e.g.:t
is assumed to be a thread identifier in the further discussion (do not confuse withThreadId
).Expected result
Messages from each thread (with the same thread identifier
t
) appear in order.Expected result
There are a few messages in a single thread (the same
t
) that appear not in order.Analysis
This is the problematic code fragment of
pushLog
function linked above:if two threads execute
atomicModifyIORef'
and for both of themcheckBuf
matches the first guard, theolomsg
will get flushed in both cases and we don't have any guarantees about the order in whichwriteLogStr
will be executed for both threads.