Hi all, 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 (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?). However, various .hi, .a files and HSrts.o also seem to differ. So is the best way forward to create two completely separate packages? Thanks Ian
Hi all,
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.)
(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.
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? 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. Cheers, Wolfgang
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
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.
Ah yes, I overlooked that, because it doesn't happen on Mac OS X :-).
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 [...]
Something like that, I guess.
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)
I don't see anything here.
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.
Dual-CPU doesn't help, as the threaded RTS still only runs one Haskell thread at a time (SMP is a lot harder). However, import Foreign foreign import ccall sleep :: Int -> IO () -- slightly wrong signature, but still works :-) main = do forkIO $ sequence_ $ repeat $ putStrLn "Hello, world." sleep 10 If the above program prints "Hello, world." like mad for 10 seconds, it's the threaded RTS; if it prints it at most a few times and then stops for 10 seconds, it's the non-threaded RTS. Hope that helps, Cheers, Wolfgang
participants (2)
-
Ian Lynagh -
Wolfgang Thaller