June 2002 - Glasgow-haskell-users

GHC 5.02.3 binaries for OpenBSD i386
by dons＠cse.unsw.edu.au 19 Jun '02

19 Jun '02

I'm pleased make available GHC 5.02.3 binaries for OpenBSD i386. Also available is a ports tree 'port' if you want to build from source. The binary package (15M) is available from: ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/ghc-5.02.3.tgz And can be installed with (as root): pkg_add ghc-5.02.3 It can be removed with (as root): pkg_delete ghc-5.02.3 If you like building from source the ports tree 'port' that built the binary package is available from: ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/ghc-5.02.3-port.tgz To build the port you first need a GHC binary on the system. The 5.02.3 binary package can be used, or you could build 4.08.2 from .hc source and use that. There is a port to do this at the above URL. You will also need the Happy parser, which you can get from: ftp://ftp.cse.unsw.edu.au/pub/users/dons/happy/happy-1.11.tgz Once you have a GHC and Happy, untar the port and as root: make && make fake At this point the compiler is built, but you must remove the old GHC before you can install the new one. So: pkg_delete ghc-4.08.2 # or whatever version of GHC you used make install This takes around 170 minutes on my P3 700. Once again, any bug reports or suggestions would be welcome. You can reach me at <dons(a)cse.unsw.edu.au>. Don

1 2

Giving profiled object files a different extension (was: RE: Profiling suggestion)
by Simon Marlow 19 Jun '02

19 Jun '02

> Re the current and recurring conflicts between profiling and > non-profiling code; how hard would it be to name GHC's output files > differently when compiling with -prof? > > I.e. without, you get the normal foo.hs -> foo.o result, but with > -prof you could get e.g. foo.po or foo.p.o instead? (And of course, > linking these instead when making the executable) > > I can probably hack this in a makefile, but it'd be nice to be able to > just ghc --make as well. We've wondered about this from time to time, but it's not clear to me that it's an all-round good idea. So if anyone else has any opinions please chime in - if the general concensus is to make this change then we'll do it. The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar. To summarise the advantages/disadvantages: - win: you could store profiled and normal objects in the same directory. - win: you'd be less likely to mix up profiled and normal objects. - lose: Makefile writing gets harder. Extra suffix rules have to be added to deal with the new suffixes, and 'make depend' has to add dependency rules for the extra suffixes (ghc -M has some support for doing this). If you're using ghc --make this doesn't affect you. Cheers, Simon

4 4

A Thread for Every Thread?
by Ashley Yakeley 18 Jun '02

18 Jun '02

At 2002-06-18 08:17, Dean Herington wrote: >Would it be feasible to support an alternative strategy for >mapping Haskell threads onto OS threads, namely that the two sets are kept >in one-to-one correspondence? I was wondering the same thing... At 2002-06-18 08:27, Simon Peyton-Jones wrote: >The current GHC model has the basic assumption that OS threads >are inter-changeable. One Haskell thread may be executed by one >OS thread or by many; you just can't tell. > >There is a good reason for this: the current OS thread may block >in some I/O call (getChar, say), and we don't want that to block >all Haskell threads. Surely with a one-to-one correspondence, this wouldn't be an issue? The one (OS/Haskell) thread would correctly block, and the others wouldn't. -- Ashley Yakeley, Seattle WA

1 0

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Marlow 18 Jun '02

18 Jun '02

> I'm slowly losing track of this discussion... so am I :-( > My initial suggestion > was that it is guaranteed that the same OS thread which created the > f.i.w. thunk is used to call back to Haskell for *this* > wrapped function. > There is no overhead for calls Haskell->C, only for the comparatively > rare case of C->Haskell. What's wrong with this? There are two problems with this approach, I think. The situation is like this (correct me if I'm wrong): - Haskell thread H1 running on OS thread O1 registers a callback C. - Haskell thread H1/O1 makes a blocking call into HOpenGL. This call is made also in O1. The RTS allocates another OS worker thread O2, and continues running Haskell threads. - HOpenGL, running in O1, invokes the callback C. The RTS stops O1, creates a new Haskell thread H2 in which to run C, and eventually runs H2 in O2. Problem #1 is the call-in: our current implementation *always* runs the callback in a different OS thread from the calling thread. It was simpler this way, but perhaps this can change. Problem #2 is that we would have to add some extra machinery to guarantee that a given Haskell thread executes in a particular OS thread, and somehow do it in a way that was "fair" (i.e. the Haskell thread with a preference for its OS thread doesn't get starved, and doesn't starve other threads). The RTS currently doesn't make any distinction between OS threads; a given Haskell thread can even migrate from one OS thread to another during its execution. Cheers, Simon

3 2

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Marlow 18 Jun '02

18 Jun '02

> Has anyone already thought about how to solve this problem? > I'm thinking about adding hooks to the RTS (in grabCapability, > releaseCapability and scheduleThread_) which would be used > for setting > up the correct thread-local state whenever Haskell execution > "switches" > to a different OS thread. Those hook routines would have to > be written > in C and would be platform-specific most of the time. It's not a nice > solution, but it's the only one I can think of at this time. > Unless someone comes up with a better idea _quickly_, I'll try it out > and then report how ugly it really is... :-) I can't see a nice solution to this problem - it really invalidates one of the key assumptions in the threaded implementation of the RTS, namely that it doesn't matter which OS thread we use to execute Haskell code. I suspect that a "safe" foreign import could be made to switch threads to the right OS thread before entering C land, but that's way too much overhead to impose on every single FFI call from Haskell. Yes, my guess is that this will probably have to be done by manipulating the thread-local state in the RTS - grab the current thread-local state whenever a call is made into Haskell, and whenever we run a Haskell thread we have to set the appropriate thread-local state. Perhaps it should be stored in the TSO and inherited by child threads too. The trouble is that there isn't a single object representing the whole thread-local state. Does OpenGL use pthread_getspecific() and pthread_setspecific() to access its thread-local state? Cheers, Simon

3 2

RE: SocketPrim Patch
by Simon Marlow 18 Jun '02

18 Jun '02

> Here's the patch to allow the setting of TTL in the IP header. > I can now send whatever value I like. Committed; thanks! Simon

1 0

SocketPrim Patch
by D.J.Steinitz 18 Jun '02

18 Jun '02

Simon, Here's the patch to allow the setting of TTL in the IP header. I can now send whatever value I like. Many thanks for all your help. Dominic. Index: SocketPrim.hsc =================================================================== RCS file: /cvs/fptools/hslibs/net/Attic/SocketPrim.hsc,v retrieving revision 1.12.2.5 diff -r1.12.2.5 SocketPrim.hsc 590a591,593 > #ifdef IP_TTL > | TimeToLive {- IP_TTL -} > #endif 621a625,627 > #ifdef IP_TTL > TimeToLive -> #const IPPROTO_IP > #endif 661a668,670 > #endif > #ifdef IP_TTL > TimeToLive -> #const IP_TTL

1 0

RE: HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 17 Jun '02

17 Jun '02

This is nasty. As I understand it, * GLUT assumes that the same OS thread executes some Haskell code, calls C, which calls back to Haskell. * Concurrent Haskell never lets this happen, for very good reason. The thread executing Haskell code is just an anonymous OS thread executing multiple Haskell threads. The good reason is this: if one designated OS thread must execute a particular bunch of Haskell code, what if that OS thread gets blocked doing I/O on behalf of some other Haskell thread? It's hard to say just which Haskell threads "belong" to that designated OS thread. The only thing I can think of is that the Haskell call-back thread somehow says that it can only be executed by the designated OS thread; and when blocks (the Haskell call-back, that is) the OS thread doesn't grab another Haskell thread to execute, but instead steps aside for an anonymous worker thread to do the job. Makes it all more complicated, alas. Is there no way to get the "current context" explicitly, and treat it as some kind of "handle" that accompanies GLUT calls? I counsel caution here. It's easy to hack something up that will puzzle us for generations. Check out Sigbjorn's notes in the GHC commentary. Whatever we end up doing should be documented there. Simon | -----Original Message----- | From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net] | Sent: 16 June 2002 20:57 | To: hopengl(a)haskell.org | Cc: GHC List | Subject: HOpenGL and --enable-threaded-rts | | | In short, it doesn't work :-( . | OpenGL (at least on MacOS) keeps track of the "current context" on a | per-thread basis. The GLUT library sets the current context and calls | back to the program. With GHC 5.03 compiled with | --enable-threaded-rts, | the callback gets executed in a different thread. There is no OpenGL | context set up for that thread, so the first OpenGL call | crashes. This might also be a problem for other state-based | interfaces that use | thread-local state. | | Has anyone already thought about how to solve this problem? | I'm thinking about adding hooks to the RTS (in grabCapability, | releaseCapability and scheduleThread_) which would be used | for setting | up the correct thread-local state whenever Haskell execution | "switches" | to a different OS thread. Those hook routines would have to | be written | in C and would be platform-specific most of the time. It's not a nice | solution, but it's the only one I can think of at this time. | Unless someone comes up with a better idea _quickly_, I'll try it out | and then report how ugly it really is... :-) | | Cheers, | | Wolfgang | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

3 2

hGetContents and threadWaitRead?
by MR K P SCHUPKE 17 Jun '02

17 Jun '02

Whilst everyone is discussing threads, does anybody know if hGetContents is well behaved with respect to threads - ie does it use threadWaitRead internally? I know it uses unsafePerfomIO, is a function that interleaves IO using unsafePerformIO automatically haskell-thread safe? - also do I need to use threadWaitWrite before any hPut - or do the hPut functions do this internally? Regards, Keean Schupke.

2 1

HGL with GHC in Win32
by S.J.Thompson 17 Jun '02

17 Jun '02

Can anyone help? I would like to run a program using the Haskell Graphics Library under GHC on Windows. HGL is listed as a package (when ghc is asked about its packages) but not actually distributed as a package with ghc-5.02.3. On trying to remedy this, - I am able to compile HGL by hand on windows, but on executing the HelloWorld.hs the program hangs: nothing happens. - HGL doesn't appear to compile on unix (solaris). I'd be grateful for any feedback. Thanks very much, Simon Thompson

2 2