<div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 1:35 PM Ian Denhardt <<a href="mailto:ian@zenhack.net">ian@zenhack.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Johannes Waldmann (2018-11-30 05:50:03)<br>
<br>
> Given that, it now feels strange that the following *does* work:<br>
><br>
> main = do<br>
>   forkIO $ do threadDelay 1000000 ; putStrLn "foo"<br>
>   forever $ putStr ""<br>
><br>
> I am seeing the "foo" output. I expect the last line<br>
> to be non-allocating. But it does still yield? Why?<br>
<br>
putStr has to acquire a lock on stdout, so that's probably enough to<br>
allow the scheduler to run.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>