main = forever (putStrLn =<< getLine) continuously saturates a CPU when compiled

[lpsmith]

$ ghc --make copycat.hs
$ ./copycat

[lpsmith]

The problem appears to be in getLine; you can remove forever and still consume 100% of a CPU (until you type something in and the program exits of course.)

[lpsmith]

Playing around with this issue a little bit more, getLine and hGet from Data.ByteString.Char8 also saturate the CPU when they block. However I do have some code that uses threadWaitRead and a C library to fetch some input (specifically, the asynchronous notification mechanism of PostgreSQL via libpq), which does not exhibit this problem.

[igloo]

Thanks for the report.

This is a regression: It works in 7.2 and 7.0.

Simon, do you know what's up?

I skimmed 6b1098511aaabd2c9503ee7be6da1944466f9cb4, and while I don't think it's relevant, shouldn't the tv_nsec and tv_usec fields in these hunks have the complete seconds removed?:

-        it.it_value.tv_sec = itimer_interval / 1000;
-        it.it_value.tv_nsec = (itimer_interval % 1000) * 1000000;
+        it.it_value.tv_sec  = TimeToSeconds(itimer_interval);
+        it.it_value.tv_nsec = TimeToNS(itimer_interval);

-        it.it_value.tv_sec = itimer_interval / 1000;
-        it.it_value.tv_usec = (itimer_interval % 1000) * 1000;
+        it.it_value.tv_sec = TimeToSeconds(itimer_interval);
+        it.it_value.tv_usec = TimeToUS(itimer_interval);

[lpsmith]

Ok, I was mistaken. The program I though I compiled with ghc-7.4.1-rc1 I actually compiled with ghc-7.0.3, and so the program I used to test threadWaitRead also saturates the CPU. Although it may not be of any great interest to the bug-hunters, I'll attach the program, it's a straightforward port of a sample program from the PostgreSQL source distribution to the  http://hackage.haskell.org/package/postgresql-libpq bindings.

So it seems to be a problem with blocking IO in general. I find it curious that none of my test programs exhibit this problem when run inside GHCi.

[igloo]

GHCi is linked with -threaded by default, which uses a different implementation of this stuff.

[lpsmith]

Oh, right, I didn't notice that the program I was writing when I ran into this bug wasn't not being linked -threaded. And this problem does go away when I do that. Thanks!

[marlowsd@…]

commit fac8ecbbafde17dd92439c41747223c43e9d2b80

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Mon Jan 16 09:49:24 2012 +0000

    Fix bug causing polling instead of blocking in the non-threaded RTS (#5773)
    
    This was a regression introduced accidentally in
    6b1098511aaabd2c9503ee7be6da1944466f9cb4.  We were previously passing
    a large time value to select() to simulate blocking, and this broke
    due to a change from unsigned to signed arithmetic.  I've refactored
    it to be less fragile now - we just pass NULL as the timeval parameter
    to select(), which is the correct way to do blocking.

 rts/posix/Select.c |   35 +++++++++++++++++------------------
 1 files changed, 17 insertions(+), 18 deletions(-)

[simonmar]

Thanks for the report - a good one to find before the release.

[igloo]

Merged as e3b7e3352c6bba0bf7b6991e5485264a868e4800

[simonmar]

The fix is faulty, I'm just validating a fix for the fix.

[simonmar]

Fix committed as d2dcac6a0291d5271bf7f8ff1394121abd6901d2

[igloo]

Merged as 7a5f8048fb4a9d620724a47d92762102089a6c9a.