[darcs-devel] [issue1026] pull => bug in get_extra commuting patch (2.x)

[Thorkil Naur]

Thorkil Naur <naur at post11.tele.dk> added the comment:

On Monday 25 August 2008 03:22, Jason Dagit wrote:
> ...
> The attached patch can be used to improve the error reporting of darcs.  I was
> hoping to try it out and see which two patches fail to commute.
>
> Can someone that can reproduce this try for me?

With your patch applied, the reaction extends to:

> Thorkil-Naurs-Computer:~/tn/test/darcs/Issue/1026/work/repo/array thorkilnaur$ 
/Users/thorkilnaur/tn/darcsDarcsRepository/darcs.net/darcs pull /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-
and-copying-20070713_1212/ghc --repodir .
> Pulling from "/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc"...
> This is the GHC darcs repository (HEAD branch)
> 
> For more information, visit the GHC developer wiki at
>   http://hackage.haskell.org/trac/ghc
> **********************
> darcs: bug in get_extra commuting patches:                                      
> First patch is:
> Fri Apr 22 19:00:49 CEST 2005  sof
>   * [project @ 2005-04-22 17:00:49 by sof]
>   [mingw only]
>   Better handling of I/O request abortions upon throwing an exception
>   to a Haskell thread. As was, a thread blocked on an I/O request was
>   simply unblocked, but its corresponding worker thread wasn't notified
>   that the request had been abandoned.
>   
>   This manifested itself in GHCi upon Ctrl-C being hit at the prompt -- the
>   worker thread blocked waiting for input on stdin prior to Ctrl-C would
>   stick around even though its corresponding Haskell thread had been
>   thrown an Interrupted exception. The upshot was that the worker would
>   consume the next character typed in after Ctrl-C, but then just dropping
>   it. Dealing with this turned out to be even more interesting due to
>   Win32 aborting any console reads when Ctrl-C/Break events are delivered.
>   
>   The story could be improved upon (at the cost of portability) by making
>   the Scheduler able to abort worker thread system calls; as is, requests
>   are cooperatively abandoned. Maybe later.
>   
>   Also included are other minor tidyups to Ctrl-C handling under mingw.
>   
>   Merge to STABLE.
> Second patch is:
> Fri May  6 02:30:57 CEST 2005  sof
>   * [project @ 2005-05-06 00:30:56 by sof]
>   [mingw only]
>   Work around bug in win32 Console API which showed up in the GHCi UI:
>   if the user typed in characters prior to the appearance of the prompt,
>   the first of these characters always came out as a 'g'. The GHCi UI does
>   for good reasons one-character reads from 'stdin', which causes the
>   underlying APIs to become confused. A simple repro case is the following
>   piece of C code:
>   
>   /*----------------------*/
>   #include <stdio.h>
>   #include <windows.h>
>   int main()
>   {
>       char ch1,ch2;
>       HANDLE hStdIn = GetStdHandle(STD_INPUT_HANDLE);
>       DWORD dw;
>   
>       /* Type in some characters before the prompt appears and be amused.. */
>       sleep(1000); printf("? ");
>       ReadConsoleA(hStdIn,&ch1,1,&dw,NULL);
>       ReadConsoleA(hStdIn,&ch2,1,&dw,NULL);
>   /*  or, if you want to use libc:
>       read(0,&ch1,1); read(0,&ch2,1); */
>   
>       printf("%c%c\n", ch1,ch2);
>       return 0;
>   }
>   /*----------------------*/
>   
>   This happens across win32 OSes, and I can't see anything untoward as far
>   as API usage goes (the GHC IO implementation uses read(), but that
>   reduces to ReadConsoleA() calls.) People inside the Behemoth might want
>   to have a closer look at this..
>   
>   Not much we can do about this except work around the problem by flushing
>   the input buffer prior to reading from stdin. Not ideal, as type-ahead
>   is a useful feature. Flushing is handled by GHC.ConsoleHandler.flushConsole
>   
>   Merge to STABLE.
> Thorkil-Naurs-Computer:~/tn/test/darcs/Issue/1026/work/repo/array thorkilnaur$ 

Best regards
Thorkil

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue1026>
__________________________________