Test concio001 failures on PPC Mac OS X

[Simon Marlow]

naur at post11.tele.dk wrote:
> Hello,
> 
> The test case concio001 fails like this on the PPC Mac OS X builder tnaur-ppc-osx, most likely because of a simple timing problem:
> 
>> =====> concio001(normal) 
>> cd . && $MAKE -s --no-print-directory test.concio001    </dev/null >concio001.run.stdout 2>concio001.run.stderr
>> Actual stdout output differs from expected:
>> --- ./concio001.stdout.normalised       2008-02-06 08:18:52.000000000 +0100
>> +++ ./concio001.run.stdout.normalised   2008-02-06 08:18:52.000000000 +0100
>> @@ -1,2 +1 @@
>> -child
>>  parent
>> *** unexpected failure for concio001(normal)
> 
> Briefly, the test uses
> 
>> (sleep 1; echo x) | ./concio001
> 
> to run the program
> 
>> $ cat concio001.hs 
>> import Control.Concurrent
>>
>> main = do
>>   forkIO $ do threadDelay  100000; putStrLn "child"
>>   getLine
>>   putStrLn "parent"
>> $ 
> 
> expecting the sleep 1 delay to be sufficient for the program to start running, performing its threadDelay and printing the "child" string, before the "parent" gets its input "x". But apparently, sleep 1 is insufficient in some cases.
> 
> If I run the test by hand, it succeeds. If I run the test alongside other processes that tries to spend disk I/O bandwith and/or CPU and/or memory, I am able to make it fail. So it appears that such circumstances are present during the buildbot running of the concio001 test.
> 
> I am not sure how to cure this. I am confident that simply increasing the sleep time would remove the problem in practice. However, perhaps some less brittle solution could be found.

While you're looking at this one, could you verify that we can now close #1523?

http://hackage.haskell.org/trac/ghc/ticket/1523

I'm going to disable this concio001 test and replace it with one that is 
hopefully more reliable, I'll push after I've validated it.

Cheers,
	Simon