IO question (hGetLine)

[Simon Marlow]

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

> Duncan Coutts 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
> 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