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