HGL broken on Windows

[guest]

The following program (example from "The Haskell School of Expression") runs very slowly, often taking a couple of minutes to create a window:

import Graphics.SOE
main	=	runGraphics (
			do	w <- openWindow "Hello" (300,300)
				drawInWindow w (text(100,200) "Hello world!")
				k <- getKey w
				closeWindow w
		 	)

Using: GHC 6.4.1 release (msi installer). System: Windows 2000 sp4, 5.00.2195 GCC: 3.4.2 (mingw-special) make:

C:\Documents and Settings\Administrator\My Documents\progging_projects\Haskell>ghc --make -v -dcore-lint main.hs
Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4
Using package config file: C:\ghc\ghc-6.4.1\package.conf
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable modules:
*** Compiling Main             ( main.hs, main.o ):
compile: input file main.hs
*** Checking old interface for Main:
Skipping  Main             ( main.hs, main.o )
*** Deleting temp files
Deleting: C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Warning: deleting non-existent C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Upsweep completely successful.
*** Deleting temp files
Deleting:
link: linkables are ...
LinkableM (Mon Apr 10 00:14:25 Eastern Daylight Time 2006) Main
   [DotO main.o]
Linking ...
*** Linker
C:\ghc\ghc-6.4.1\gcc -BC:\ghc\ghc-6.4.1\gcc-lib/ -v -o main.exe -DDONT_WANT_WIN32_DLL_SUPPORT main.o -LC:/ghc/ghc-6.4.1
-LC:/ghc/ghc-6.4.1/gcc-lib -lHSHGL -lHSWin32 -lHSWin32_cbits -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lH
Sbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _GHCziBase_Izh_static_info -
u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info
-u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_inf
o -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_stat
ic_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_C
zh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_in
fo -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString
_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closu
re -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closur
e -u _GHCziWeak_runFinalizzerBatch_closure -u ___stginit_Prelude
Reading specs from C:/ghc/ghc-6.4.1/gcc-lib/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
 --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --ena
ble-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
 C:/ghc/ghc-6.4.1/gcc-lib/collect2.exe -Bdynamic -o main.exe -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info
 -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_inf
o -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_
info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_
static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_F
zh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u _GHCziStable_StablePtr
_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_sta
ckOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOn
DeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziWeak_runFinalizze
rBatch_closure -u ___stginit_Prelude C:/ghc/ghc-6.4.1/gcc-lib/crt2.o C:/ghc/ghc-6.4.1/gcc-lib/crtbegin.o -LC:/ghc/ghc-6.
4.1 -LC:/ghc/ghc-6.4.1/gcc-lib -LC:/ghc/ghc-6.4.1/gcc-lib -L/mingw/lib/gcc/mingw32/3.4.2 -L/mingw/lib/gcc/mingw32/3.4.2/
../../../../mingw32/lib -L/mingw/lib -L/mingw/lib/gcc/mingw32/3.4.2/../../.. main.o -lHSHGL -lHSWin32 -lHSWin32_cbits -l
user32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lHSbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -l
HSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw
32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/ghc/ghc-6.4.1/gcc-lib/crtend.o
link: done

[igloo]

With 6.6, this normally seems to deadlock, but sometimes it works. Unfortunately debugging prints make it work once you get close enough to the problem. I'm not sure if HGL or GHC is at fault.

[simonmar]

These might be related: #1081, #471

[simonmar]

My (limited) analysis of this bug is that the delicate scheduling assumptions made by the HGL library are now broken on Win32. From a brief look at the code, it seems that HGL has some carefully-placed yields in order to give other threads a chance to run, and my guess is that the current placement of yields is not sufficient in the case of GHC.

Simply using -threaded isn't going to work on its own, because the Win32 graphics API is single-threaded. The right way to fix this would be to modify the HGL library to talk to the Win32 graphics API from a single bound thread. However it may be better to abandon this implementation in favour of the Gtk one:

 http://www.haskell.org/pipermail/haskell/2006-August/018398.html

I'm removing this bug from the 6.6.1 milestone. We didn't ship HGL in 6.6 on Windows anyway.

[duncan]

We could do with some help in verifying that the Gtk implementation of SOE preserves the semantics of the original as closely as possible.

It is included in the latest release of  Gtk2Hs so should be easy to try out on all platforms (including Windows for which there is an installer available).

[igloo]

No longer an extralib, so closing the bug