[Haskell-cafe] semantics of concurrent program depends on -O level, -f[no-]omit-yields

[Brandon Allbery]

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 at 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 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181130/004180d0/attachment.html>