RE: unexpected space leak
It's a hack we put in, because fixing the bytecode generator properly for this relatively obscure case was a lot of effort and other calls on our time (we were stabilising for the 5.02 release at the time) were more pressing. It is (nearly) harmless. What usually causes it is having strict polymorphic fields on constructors: data T a = T !a The warning is intended to mean that the strictness annotation will be ignored in interpreted code. This shouldn't have any effect on the overall outcome of your program, unless it depends on evaluation order changes induced by the !, for some gruesome reason. However, the space behaviour may well be different from what it would be if ! was observed. If you do experience problems as a result of this, I'd be interested to hear of them. J | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, December 19, 2001 11:22 PM | To: GHC Users Mailing List | Subject: unexpected space leak | | | what does it mean when ghci says: | | WARNING: ignoring polymorphic case in interpreted mode. |Possibly due to strict polymorphic/functional constructor args. |Your program may leak space unexpectedly. | | | -- | Hal Daume III | | "Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-3.02 (maybe OFF-time)
Hi all: I'm hacking with ghc-3.02.src.tar.gz on several platforms, namely i386 and sparc ... Both platforms run with gcc-2.7.2.3 ( higher versions may be a risk , 2.95 was bad...) In sparc I have no problems, but in i386 I do obtain the next results (File : fptools/ghc/lib/posix/PosixProcPrim.hc) "../../../ghc/driver/ghc -i../misc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O '-#include"cbits/libposix.h"' -c PosixProcPrim.hc -o PosixProcPrim.o -osuf o PosixProcPrim.hc:2244: fixed or forbidden register was spilled. This may be due to a compiler bug or to impossible asm statements or clauses." I think cc1 is reducing uncorrectly to asm code. Reading documents on gcc, I got this... ( File: /usr/docs/gcc/PROBLEMS ) May be has nothing to do... "3. When find_reloads is used to count number of spills needed it does not take into account the fact that a reload may turn out to be a dummy." May be this is rather a question for gcc , but... Does any body know where to add any flag to help gcc to reduce OK ? I tried no -O flag , -O2 ,-O1, but no sucess... Regards... Martinez-Torres. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC-3.02 (maybe OFF-time)
> I'm hacking with ghc-3.02.src.tar.gz on several platforms, namely i386 > and sparc ... > > Both platforms run with gcc-2.7.2.3 ( higher versions may be a risk , > 2.95 was bad...) > > In sparc I have no problems, but in i386 I do obtain the next results > (File : fptools/ghc/lib/posix/PosixProcPrim.hc) > > "../../../ghc/driver/ghc -i../misc -recomp -cpp -fglasgow-exts -fvia-C > -Rghc-timing -O '-#include"cbits/libposix.h"' -c > PosixProcPrim.hc -o > PosixProcPrim.o -osuf o > PosixProcPrim.hc:2244: fixed or forbidden register was spilled. > This may be due to a compiler bug or to impossible asm > statements or clauses." You need to give GHC the -monly-3-regs (or possibly -monly-2-regs) option. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
`forkProcess` creates an exact copy of the calling process, except for the return value from `forkProcess` that allows for discriminating the parent from the child. In your example, there are two active threads at the time `forkProcess` is done, so the new process has (copies of) the same two active threads. Then the race is on in the new process: depending on the (unspecified) order of execution, the copy of the initial thread may get to the `print` before its sibling thread gets to do `executeFile` (which wipes away both existing threads). This example raises a general problem (which, as it turns out, is relevant to my current work). How can one mix multithreading with multiprocessing? In particular, how can a threaded process safely create another process to run a program? Put another way, how can the combination of `forkProcess` and `executeFile` be done "atomically enough" so that existing threads in the forking process don't "get in the way". I read something on this topic (involving some sort of pervasive locking strategy) recently, but can't recall where. Anybody remember? Dean Herington Marcus Shawcroft wrote: > Hi, > > I want to use a thread in concurrent haskell to manage a posix > fork/exec/wait. I expected the test code attached below to output > "recovering result" once, instead I get "recovering result" twice. Can > anyone shed some light on whats going wrong? > > (ghci 5.02.1 x86 linux) > > Thanks > /Marcus > > > module Test where > > > import Concurrent > > import Posix > > > main = do > > mv <- newEmptyMVar > > forkIO $ do x <- forkProcess > > case x of > > Nothing -> do > > executeFile "sleep" True ["2"] Nothing > > error "oops" > > Just pid -> > > getProcessStatus True False pid > > putMVar mv () > > print "recovering result" > > takeMVar mv ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
