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

[Thorkil Naur]

Hello,

On Thursday 19 July 2007 12:20, Simon Marlow wrote:
> Manuel M T Chakravarty wrote:
> 
> > * 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.
> 
> Bizarre.  I have absolutely no idea why that might happen, and it doesn't 
seem 
> to happen here on Linux.  Any clues from ktrace?  Does this happen with and 
> without -threaded?

On my PPC Mac, it happens with -threaded only. Here is a session:

> $ cat concio001.hs
> import Control.Concurrent
>
> main = do
>   forkIO $ do threadDelay  100000; putStrLn "child"
>   l <- getLine
>   putStrLn $ "parent got <" ++ l ++ ">"
> $ make TEST=concio001.thr
> ...
> $ ./concio001
> child
> First line
> Second line
> parent got <Second line>
> $ ./concio001
> q
> child
> parent got <q>
> $ ./concio001
> q
> parent got <q>
> $ (sleep 1; echo "p") | ./concio001
> child
> parent got <>
> $ (sleep 1; echo "p") | ./concio001 >concio001.tmp.stdout
> $ od -a concio001.tmp.stdout
> 0000000    c   h   i   l   d  nl   p   a   r   e   n   t  sp   g   o   t
> 0000020   sp   < nul nul   >  nl
> 0000026
> $

Here, "First line" is typed after waiting for the "child" output. The "Second 
line" is then typed when nothing happens after that. As can be observed, the 
parent thread captures the second line.

In the two next runs of concio001, the "q" is typed quickly, immediately after 
the newline that ends the command. Observe that the "child" sometimes get a 
saying here. But the q is captured buy the parent in both cases and there is 
no need for an additional line.

The last case may help to understand what happens.

> 
> > * 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?
> 
> I think this is a trace from the -threaded version, right?  The use of a 
> blocking read() is expected (we don't use O_NONBLOCK for stdin any more), 
and 
> the SIGALRMs are caused by the RTS's normal interval timer.  One of my 
patches 
> yesterday changed the default interval from 50ms to 20ms, which may explain 
why 
> you see more of these than before.
> 
> Cheers,
> 	Simon
> 
> 
> 

Best regards
Thorkil