Hm, has that been optimized to output all at once? The implementation I
recall is more or less mapM_ putChar, deferring the lock to putChar which
never gets invoked because the list is empty.
Okay, just checked; it reserves the handle up front, and then the above
implementation (albeit directly instead of via mapM_) is used only in the
NoBuffering case, using an internal function that doesn't reserve. Which
will complicate understanding what's going on, although my suggestion
earlier about unbuffering output still applies.
On Fri, Nov 30, 2018 at 1:35 PM Ian Denhardt
Quoting Johannes Waldmann (2018-11-30 05:50:03)
Given that, it now feels strange that the following *does* work:
main = do forkIO $ do threadDelay 1000000 ; putStrLn "foo" forever $ putStr ""
I am seeing the "foo" output. I expect the last line to be non-allocating. But it does still yield? Why?
putStr has to acquire a lock on stdout, so that's probably enough to allow the scheduler to run. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh allbery.b@gmail.com