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 <ian@zenhack.net> wrote:
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