- Glasgow-haskell-users

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

| My proposal is to leave dealing with thread-local state to | the library | binding (in this case, HOpenGL). This requires just a little support | from the RTS. The library binding would have to include C-language | routines that get called by the RTS at certain points: | * when the RTS starts executing Haskell code in an OS thread | (grabCapability) | * when the RTS stops executing Haskell code in an OS thread | (releaseCapability) | * when the RTS is about to spawn a new thread in response to | a callback (scheduleThread_). That might be ok provided there was a single context "in play". In effect, your proposal amounts to keeping a process-global context, and zapping it into the Current Haskell Worker Thread whenever it grabs a capability, correct? But if there's a single global context, why does it need to be thread-local? Another possibility that Simon and I have discussed is to provide a sort of forkIO that says "create a Haskell thread permanently bound to an OS thread". Much more expensive than normal forkIO. More like having a permanent secretary at your beck and call, rather than the services of a typist from the typing pool. Simon

3 2

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

20 Jun '02

> This sounds like a lot of work and a porting nightmare (what do you > mean Linux/Win32/HPUX/... doesn't have thread manipulation function X, > it's available on FreeBSD/Win32/... What if there are other forms > of thread-local state (e.g., errno)? What about setjmp/longjmp?). Yes, these are all problems. However, there is a nice abstraction of the OS thread API in GHC's RTS, thanks to Sigbjorn. So I'm sure this API could be extended to include some thread-local state operations. > The only viable solution I can see is to provide a way to capture the > calling thread (as a first class entity) when you call into Haskell > and to explicitly specify whcih thread to use when you call out from > Haskell. (Hmmm, sounds like callcc for C :-)) The trouble is, that is *way* too much overhead for a C call. HOpenGL does lots of these, and I strongly suspect that adding a full OS-thread context switch (well two, including the return) for each one would be a killer. Cheers, Simon

5 6

when is compilation necessary
by Hal Daume III 19 Jun '02

19 Jun '02

suppose i have three modules: > module Foo(foo) where > foo x = x + 1 > module Bar(bar) where > import Foo > bar x = foo (x+1) > module Main(main) where > import Bar > main = print (foo 5) Now, suppose I change Foo.hs so that "foo x = x + 2". If I ghc --make on Main, it will build Foo, then Bar, then Main, then link. Is all of this necessary or can I (manually) just rebuild Foo and then relink? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

New MacOS X snapshot
by Wolfgang Thaller 19 Jun '02

19 Jun '02

I've uploaded a new snapshot of GHC for MacOS X at http://www.uni-graz.at/imawww/haskell/GHC.dmg It's a few days behind current CVS, but it also includes a change that I haven't yet commited to CVS (using a framework named HaskellSupport.framework which contains libdl and libgmp), The main reason I've made a snapshot now is that someone asked me for help with the old snapshot from March... Is it possible to announce this on the GHC news page so that people don't accidentally download the old snapshot (which should be removed from the haskell.org server)? Cheers, Wolfgang

1 0

simple backtraces in ghci
by Hal Daume III 19 Jun '02

19 Jun '02

Hi all, Currently, I've been using the following hack to do backtraces: namedEx :: String -> a -> a namedEx fname x = unsafePerformIO $ Exception.catch (x `seq` return x) (\ex -> ioError (UserError (fname ++ " : " ++ show ex))) At which point, if I have a function foo ... = ..., I change it to foo ... = namedEx "foo" $ ... For instance: foo l = namedEx "foo" $ if head (bar l) == 1 then True else foo (tail l) bar l = namedEx "bar" $ head l This way I effectively get a backtrace as is offered in Java, SML/NJ, Python and countless other languages. I know that GHC is somewhat intelligent about handing Exception.assert, where it will automatically insert module names and line numbers for you, if you want. I was wondering if there was any chance of something like this getting hard coded in. I would want this turned off by default for compiled code, but for code loaded in ghci, I find it very useful... - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

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

19 Jun '02

> Hal Daume III <hdaume(a)ISI.EDU> writes: > > > For what it's worth (I don't know whether defaulting -prof > to mean '-prof > > -osuf p_o -hisuf p_hi' was going to be adopted or not), but > I'm against > > it. > > Yep. I don't remember if I was the one raising the issue or just > participating, but I'm perfectly satisfied with the -osuf and -hisuf > options (which I hadn't discovered at the time). > > (I still advocate generating a warning/error when GHC is used to link > profiling and non-profiling object files, though. But as it never > happens anymore, it's not a big deal.) Thanks for the feedback. I don't think we'll change the default, but we will add some kind of consistency checking at some point. Cheers, Sim

1 0

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