On 14 June 2004 16:58, Gerd M wrote:

...

The GHC run time system is designed to block without using CPU when all threads are blocked doing IO. Could you give more details? It would be useful to see the code or preferably a small test case that demonstrates your problem. What version of ghc are you using? Which OS are you running that on? I'm using ghc-6.2.1 to compile in 32bit mode while i'm running the

Duncan Coutts wrote: program in 64bit (Linux Kernel 2.6.5, amd64) with the 32bit emulation libraries. I don't think that is the problem spot because all other 32bit application are working fine.

mainLoop dev = do inp <- hGetLine dev (runIndexCmd . parseInput) inp return ()

This is called from main with: devHandle <- openFile device ReadMode ................... catchJust asyncExceptions (forever (mainLoop devHandle)) (cleanup devHandle)

forever = a >> forever a

The module that manages the device puts a process to sleep with interruptible_sleep_on( queue ) if there's no data available and wakes it up as soon as input arrives. As i said before this works when i use "cat".

GHC uses non-blocking I/O operations and select() to manage multi-threaded I/O, which would explain why you are seeing different behaviour compared to cat(1). If this is a home-grown device, I respectfully suggest :-) that you check the behaviour of the device when used with non-blocking I/O and select(). Try strace to see what system calls are in the loop. If it is select(), then perhaps the device is wrongly flagging select() when there is no data available? Cheers, Simon