threaded-rts

Ian Lynagh igloo@earth.li
Tue, 22 Jul 2003 20:01:27 +0100


On Tue, Jul 22, 2003 at 08:11:03PM +0200, Wolfgang Thaller wrote:
> >
> >I've had a request for --enable-threaded-rts support in the Debian
> >packages, but I don't want to just build with it as then HOpenGL can't
> >be used.
> >
> >My hope was that I could share most files and just have a different
> >binary or something for the threaded-rts
> 
> This is indeed the case. The threaded-rts switch only affects the 
> runtime system, that is, libHSrts.a and libHSrts_p.a.
> And of course, it affects all programs compiled by GHC; you should also 
> ship two versions of the GHC binary itself, so that users can use ghci 
> with or without the threaded rts.
> Apart from that, you should be able to share everything else. (I think 
> you can get away with just one version for the other utilities, they 
> should behave the same in both cases.)

That, along with your HSrts.o later, ties in with the files that change
file size except that /usr/lib/ghc-6.0/package.conf gains a "pthread" in
the rts extra libraries.

It looks like I want to make a package-threaded.conf that thinks the rts
package is 'hs_libraries = ["HSrts-threaded"],' which I install into the
same directory and then change ghc/compiler/main/SysTools.lhs to use
this name in initSysTools when making the threaded rts version.

Oh, and I probably want another ghc-pkg that knows about
package-threaded.conf too.

> > (it would be even better if a
> >threaded-rts enabled binary could have it disabled by a +RTS flag, but 
> >I
> >don't think this is possible?).
> 
> Possible: probably, but replacing all the #ifdefs by runtime checks 
> would be quite some work.

I meant possible at the moment - just checking I hadn't missed
something.

> >However, various .hi, .a files and HSrts.o also seem to differ. So is
> >the best way forward to create two completely separate packages?
> 
> HSrts.o contains the same code as libHSrts.a; however, I think it is 
> never used; the other .o files are for GHCi, but AFAICT, GHCi never 
> loads a second copy of the runtime system (nor should it). I think you 
> can ignore this file, but if you want to be absolutely safe, make two 
> versions of it or ask SimonM.
> 
> As for the .hi files... no idea why they should be different, the 
> configure flag absolutely positively doesn't affect how the libraries 
> are built - do the hi files perhaps contain a timestamp or something 
> else that might change on its own?

Could be - looking at one of the .a files at random (libHSposix.a) it
looks like it is the timestamps of the files inside it that has
changed.

FWIW the .hi differences on /usr/lib/ghc-6.0/imports/GHC/Int.hi are:
(again chosen at random) (note that these are not contiguous)

-00006fb0  00 14 bc 84 08 00 01 00  00 00 0c 00 00 00 04 1c  |...............|
+00006fb0  00 10 bb 84 08 00 01 00  00 00 0c 00 00 00 04 1c  |...............|
-00007130  00 14 bc 84 08 00 01 00  00 00 0c 00 00 00 04 1c  |...............|
+00007130  00 10 bb 84 08 00 01 00  00 00 0c 00 00 00 04 1c  |...............|
-00013ae0  03 01 00 00 00 01 00 00  00 08 02 00 00 00 10 a4  |...............|
-00013af0  1c 41 00 01 00 00 00 01  00 00 00 00 00 00 75 00  |.A............u.|
+00013ae0  03 01 00 00 00 01 00 00  00 08 02 00 00 00 50 1e  |..............P.|
+00013af0  7c 08 00 01 00 00 00 01  00 00 00 00 00 00 75 00  ||.............u.|
-00013b30  00 00 e0 a4 2b 40 00 01  00 00 00 01 00 00 00 00  |..+@..........|
+00013b30  00 00 50 1e 7c 08 00 01  00 00 00 01 00 00 00 00  |..P.|...........|

but they are the same when I --show-iface both of them.

I think I'll assume the differences aren't important unless a problem
shows up, anyway.

> In my development builds, I've successfully switched between threaded 
> and non-threaded by just "make"ing and "make install"ing in the ghc/rts 
> directory, and then re-linking the compiler.

OK, thanks.

One more thing - is there an easy way to check to see if it has worked?
I assume a Haskell program can't tell whether or not it is being run in
a threaded-rts? I have access to a dual-CPU machine so I can time things
with and without if that makes sense.


Thanks
Ian