patch applied (testsuite): Bump the delay for concio from 0.45 to 1s

[Manuel M T Chakravarty]

Simon Marlow wrote:
> I discovered why we get all those extra select() calls (see patch I just 
> pushed).  Also we round up the delay to the next tick interval (was 
> 50ms, now 20ms), this is necessary to ensure that we sleep at least as 
> long as the given delay.
> 
> It seems that select() still sleeps for significantly longer than the 
> required delay sometimes (on Linux), so perhaps that is what you're 
> seeing, but to a greater extent.
> 
> Could you let me know whether the patches I just pushed make any 
> difference? Also I'd be interested in knowing if -threaded makes any 
> difference.

It reduces the delay somewhat.  On my x86/MBP "sleep 0.3" is 
now sufficient whereas it had to be 0.45 before.  However, 
the *behaviour* of concio001 also changed in a strange way:

* If I run concio001 *manually*, I need to press <ret>
   *twice* before it prints "parent".  However,

     (sleep 0.3; echo x) | ./concio001

   still works.  So, the behaviour seems to depend on whether
   stdin is connected to the terminal or a pipe.

* The ktrace changed dramatically.  No superfluous select()
   calls anymore.  However, the read() call is aborted a
   number times by a SIGALRM signal, which results in a
   couple of syscall restarts for read().  Maybe this causes
   a delay.  You can have a look here:

     http://www.cse.unsw.edu.au/~chak/concio001.ktrace.txt

   (This trace is from running the actual (sleep 0.3; echo x)
   test and not a manual run.)

Why does the RTS set an alarm?

BTW, I notice that Apple's BSD man page specifies that 
read() transparently restarts if it is interrupted by a 
signal, whereas Linux doesn't transparently restart any 
system calls IIRC.

There seems to be no difference between conc0001 and 
conc001.thr; at least, they require the same delay.

Manuel