A ghc-6.10.1 bug or a feature?
Hello people, I've recently tried this: $ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted. Prelude> writeFile "/tmp/test.txt" "12345\n" Prelude> b <- readFile "/tmp/test.txt" Prelude> length b `seq` b "12345\n" Prelude> The main problem is the "C^Interrupted." above. The input doesn't get read out till the end of the file for some reason when dealing with files in /sys directory (tried also others: /sys/devices/plaform/coretemp.0/temp1_input or /sys/devices/system/cpu/cpu0/cpufreq/cpufreq_cur_freq). Sometimes, the string from file in /sys gets read (with a slow delay), but most of the times it didn't. Everything works fine for a file in /tmp. Cat-ing files from shell works perfectly in /sys and /tmp. I tried also other machine: % uname -smpr Linux 2.6.28-ARCH i686 Intel(R) Pentium(R) 4 CPU 2.00GHz with the same effect. I didn't have this problem with ghc-6.8.2. Any idea? -- Juraj
On Wed, Jan 28, 2009 at 7:56 AM, Juraj Hercek
Hello people,
I've recently tried this:
$ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted. Prelude> writeFile "/tmp/test.txt" "12345\n" Prelude> b <- readFile "/tmp/test.txt" Prelude> length b `seq` b "12345\n" Prelude>
The main problem is the "C^Interrupted." above. The input doesn't get read out till the end of the file for some reason when dealing with files in /sys directory (tried also others: /sys/devices/plaform/coretemp.0/temp1_input or /sys/devices/system/cpu/cpu0/cpufreq/cpufreq_cur_freq). Sometimes, the string from file in /sys gets read (with a slow delay), but most of the times it didn't. Everything works fine for a file in /tmp. Cat-ing files from shell works perfectly in /sys and /tmp.
I tried also other machine: % uname -smpr Linux 2.6.28-ARCH i686 Intel(R) Pentium(R) 4 CPU 2.00GHz
with the same effect. I didn't have this problem with ghc-6.8.2.
Any idea?
Well readFile is a lazy getContents: The getContentshttp://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v%3AgetC... operation returns all user input as a single string, so per the documentation reading the whole file is the documented behavior.
-- Juraj _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 2009-01-28 at 16:56 +0100, Juraj Hercek wrote:
Hello people,
I've recently tried this:
$ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted.
http://hackage.haskell.org/trac/ghc/ticket/2971 Files in /proc and /sys are not select()able which messes up ghc's IO system. It's not entirely clear what changed between 6.8 and 6.10 that means we hit this now. (I'd have expected it never to have worked given that ghc has always used non-blocking IO.) Duncan
Duncan Coutts wrote:
On Wed, 2009-01-28 at 16:56 +0100, Juraj Hercek wrote:
Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted.
http://hackage.haskell.org/trac/ghc/ticket/2971
Files in /proc and /sys are not select()able which messes up ghc's IO system. It's not entirely clear what changed between 6.8 and 6.10 that means we hit this now. (I'd have expected it never to have worked given that ghc has always used non-blocking IO. Interesting. It looks like it works when I use non-lazy interface for file reading (withFile "/sys/devices/system/cpu/online" ReadMode hGetLine). Does this non-lazy interface use select too? In other words, is it only a good luck that it works?
-- Juraj
On Thu, 2009-01-29 at 17:37 +0100, Juraj Hercek wrote:
Duncan Coutts wrote:
On Wed, 2009-01-28 at 16:56 +0100, Juraj Hercek wrote:
Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted.
http://hackage.haskell.org/trac/ghc/ticket/2971
Files in /proc and /sys are not select()able which messes up ghc's IO system. It's not entirely clear what changed between 6.8 and 6.10 that means we hit this now. (I'd have expected it never to have worked given that ghc has always used non-blocking IO.
Interesting. It looks like it works when I use non-lazy interface for file reading (withFile "/sys/devices/system/cpu/online" ReadMode hGetLine). Does this non-lazy interface use select too? In other words, is it only a good luck that it works?
Ah but that's doing something quite different. You're only asking for the first line of input (in a file which presumably is only one line long). If you did hGetLine in a loop until there was no more input then you would get the same problem. So it's not to do with strict/lazy it's checking to see if there is more data available that is the problem (I think). Clearly we're not sure exactly what is going on, after all it worked in 6.8 and now doesn't in 6.10 and both use essentially the same strategy for non-blocking IO. Duncan
participants (3)
-
David Leimbach -
Duncan Coutts -
Juraj Hercek