Repository navigation
hPutStrLn in multiple threads #442
Description
Function to print text with newline performs it as two separate actions - first is to print message and second - to
print newline symbol.
This way there is issues with computations in multiple threads, so newline symbol sometimes printed in wrong place.
Possible solution here is to redefine hPutStrLn like this:
hPutStrLn :: Handle -> Text -> IO ()
hPutStrLn h t = hPutStr h $ t <> '\n'
Not sure what is the reason of current implementation..
I found that issue when used co-log and I've provided PR with a fix (co-log/co-log#243), but the source problem is text library.
Activity
phadej commentedon Jun 6, 2022
I'd rather document that none of
IOactions inData.Text.IOare thread-safe. Making them thread-safe would add an overhead for people who don't need that.EDIT: And e.g. if people need to output two lines, thread-safe
hPutStrLnwon't help.hPutStrLn $ firstLne <> "\n" <> secondLineis inefficient (performs unnecessary copying).worm2fed commentedon Jun 6, 2022
@phadej yes, such a note can be useful to avoid confusion
Bodigrim commentedon Jun 6, 2022
bytestringdefineshPutStrLnas below:This is still not atomic, but much less annoying in practice. I think doing the same trick in
text+ expanding documentation is a reasonable way to proceed.worm2fed commentedon Jun 21, 2022
@Bodigrim but length can be expensive O(n)
Bodigrim commentedon Jun 22, 2022
@axman6-da
hPutBuilderis a sensible addition, but I'm not sure it provides guarantees of atomicity even inbytestring.Bodigrim commentedon Feb 21, 2024
This seems to be a duplicate of #242.
It would be nice if someone has energy if not fix it completely then at least alleviate in typical scenarios.