[From nobody Wed Jun 20 15:24:20 2007 Received: from circe.telenet-ops.be (circe.telenet-ops.be [195.130.132.51]) by nocme2bl8.telenet-ops.be (Postfix) with ESMTP id 8AD6A158034 for <bf3@telenet.be>; Sat, 16 Jun 2007 01:50:52 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nocme2bl8.telenet-ops.be (Postfix) with SMTP id 90DBA158037 for <bf3@telenet.be>; Sat, 16 Jun 2007 01:50:52 +0200 (CEST) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by circe.telenet-ops.be (Postfix) with ESMTP id 8311233E8E for <bf3@telenet.be>; Sat, 16 Jun 2007 01:50:52 +0200 (CEST) Received: from dhcp0714.gradacc.ox.ac.uk ([129.67.90.202] helo=localhost) by smtp0.mail.ox.ac.uk with esmtp (Exim 4.63) (envelope-from <duncan.coutts@worc.ox.ac.uk>) id 1HzLZ5-0004df-1y; Sat, 16 Jun 2007 00:50:51 +0100 Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.62) (envelope-from <duncan.coutts@worc.ox.ac.uk>) id 1HzLZ6-0002lY-3K; Sat, 16 Jun 2007 00:50:52 +0100 Received: from nocme2bl8.telenet-ops.be (nocme2bl8.telenet-ops.be [195.130.136.12]) by hoboi2bl5.telenet-ops.be (8.13.1/8.13.1) with ESMTP id l5FNoqil030050 for <bf3@telenet.be>; Sat, 16 Jun 2007 01:50:52 +0200 Received: (qmail 23620 invoked from network); 15 Jun 2007 23:50:54 -0000 Received: from hoboi2bl5.telenet-ops.be ([195.130.137.88]) (envelope-sender <duncan.coutts@worc.ox.ac.uk>) by kreusa.telenet-ops.be (qmail-ldap-1.03) with SMTP for <bf3@telenet.be>; 15 Jun 2007 23:50:54 -0000 Return-Path: <duncan.coutts@worc.ox.ac.uk> From: "Duncan Coutts" <duncan.coutts@worc.ox.ac.uk> To: <bf3@telenet.be> Cc: <haskell-cafe@haskell.org> References: <001f01c7af92$3eafe7b0$bc0fb710$@be> In-Reply-To: <001f01c7af92$3eafe7b0$bc0fb710$@be> Subject: Re: [Haskell-cafe] GHCI hangs on Gtk2HS SOE on Windows, but GHC works fine? Date: Sat, 16 Jun 2007 01:50:12 +0200 Message-ID: <1181951412.5026.83.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C7B382.1EBE3210" X-Mailer: Evolution 2.6.1 X-SpamCatcher-Score: 64 [XX] Thread-Index: AcevqALRwx68OGdfQn+GrPTeXC07Lg== This is a multipart message in MIME format. ------=_NextPart_000_004D_01C7B382.1EBE3210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Fri, 2007-06-15 at 23:15 +0200, bf3@telenet.be wrote: > I'm learning Haskell using Paul Hudak's book SOE. > > I'm using GHC 6.6 under Windows XP. > > GHC on Windows does not seem to come with HGL (is this correct?), so I used > Gtk2HS, which contains a SOE implementation. > > I noticed that most programs hang when using GHCI, but they work fine with > GHC. It's not GHCi's fault as such. The reason it does not work well in GHCi at the moment is a bit technical. The Gtk2Hs SOE implementation currently uses Haskell threads. Like most GUI toolkits, Gtk+ is single threaded and requires special attention to use it from multiple OS threads. Currently, by default, GHC produces executables that use the single-threaded runtime system, and this works fine with multiple Haskell threads because they get multiplexed on the same OS thread. GHC can however produce executables that use the multi-threaded runtime system and ghci.exe itself is such a program. So when you use SOE with GHCi it's actually using multiple threads to access Gtk+ an not in a safe way, so it goes wrong in a myriad of ways. I'll take another look at trying to make the SOE stuff work with the threaded runtime system by using the primitives Gtk2Hs provides to use Gtk+ safely from multiple threads. Duncan ------=_NextPart_000_004D_01C7B382.1EBE3210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 08.00.0681.000"> <TITLE>Re: [Haskell-cafe] GHCI hangs on Gtk2HS SOE on Windows, but GHC = works fine?</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>On Fri, 2007-06-15 at 23:15 +0200, bf3@telenet.be = wrote:</FONT> <BR><FONT SIZE=3D2>&gt; I'm learning Haskell using Paul Hudak's book = SOE. </FONT> <BR><FONT SIZE=3D2>&gt; </FONT> <BR><FONT SIZE=3D2>&gt; I'm using GHC 6.6 under Windows XP.</FONT> <BR><FONT SIZE=3D2>&gt; </FONT> <BR><FONT SIZE=3D2>&gt; GHC on Windows does not seem to come with HGL = (is this correct?), so I used</FONT> <BR><FONT SIZE=3D2>&gt; Gtk2HS, which contains a SOE = implementation.</FONT> <BR><FONT SIZE=3D2>&gt; </FONT> <BR><FONT SIZE=3D2>&gt; I noticed that most programs hang when using = GHCI, but they work fine with</FONT> <BR><FONT SIZE=3D2>&gt; GHC.</FONT> </P> <P><FONT SIZE=3D2>It's not GHCi's fault as such. The reason it does not = work well in GHCi</FONT> <BR><FONT SIZE=3D2>at the moment is a bit technical. The Gtk2Hs SOE = implementation</FONT> <BR><FONT SIZE=3D2>currently uses Haskell threads. Like most GUI = toolkits, Gtk+ is single</FONT> <BR><FONT SIZE=3D2>threaded and requires special attention to use it = from multiple OS</FONT> <BR><FONT SIZE=3D2>threads. Currently, by default, GHC produces = executables that use the</FONT> <BR><FONT SIZE=3D2>single-threaded runtime system, and this works fine = with multiple</FONT> <BR><FONT SIZE=3D2>Haskell threads because they get multiplexed on the = same OS thread. GHC</FONT> <BR><FONT SIZE=3D2>can however produce executables that use the = multi-threaded runtime</FONT> <BR><FONT SIZE=3D2>system and ghci.exe itself is such a program. So when = you use SOE with</FONT> <BR><FONT SIZE=3D2>GHCi it's actually using multiple threads to access = Gtk+ an not in a</FONT> <BR><FONT SIZE=3D2>safe way, so it goes wrong in a myriad of = ways.</FONT> </P> <P><FONT SIZE=3D2>I'll take another look at trying to make the SOE stuff = work with the</FONT> <BR><FONT SIZE=3D2>threaded runtime system by using the primitives = Gtk2Hs provides to use</FONT> <BR><FONT SIZE=3D2>Gtk+ safely from multiple threads.</FONT> </P> <P><FONT SIZE=3D2>Duncan</FONT> </P> </BODY> </HTML> ------=_NextPart_000_004D_01C7B382.1EBE3210-- ]