[GHC] #3081: Double output after Ctrl+C on Windows

[Simon Marlow]

Neil Mitchell wrote:
>>> system "cp foo foo.bup" >> deleteFile "foo"
>>>
>>> If I Ctrl+C during the cp did I just delete my one copy of foo?
>> On Windows, Ctrl-C will unblock a blocked system call.  e.g. read() returns
>> with zero.  Apparently system "foo" also returns as soon as you press
>> Ctrl-C, I'm not entirely sure why.  Perhaps because the program has been
>> killed?
> 
> So, to check my understanding:
> 
> * Haskell program invokes system
> * Use presses Ctrl+C
> * System returns and Haskell program continues executing
> * Ctrl+C is thrown and Haskell program aborts

Yes.

> That sounds really dangerous - like a race condition between the
> system returning and the Haskell program aborting.

I don't know why system returns, but one valid reason would be if the child 
process had died due to the same Ctrl-C.  As Duncan says, in this case we 
ought to raise the Ctrl-C exception in the parent, but (a) none of this is 
implemented in the current process library, and (b) I'm not sure if you can 
tell whether a child died due to Ctrl-C on Windows.

Also since Windows has no process groups, I don't think system is returning 
  as a result of the child dying.  It's more likely to be returning because 
of some silly Win32ism, like the way read() returns 0 on Windows when you 
press Ctrl-C.  The latter also leads to very strange behaviour unless you 
check for it (which we don't, and we probably should).

Consoles are very weird on Windows.  Ctrl-C doesn't even work at all in 
MSYS or (certain types of) Cygwin windows, or xterms - it kills the 
program, but the program doesn't get a signal.

Cheers,
	Simon