Signal inconsistency between GHC and GHCi
After some hours of debugging Haskell code which involves the FFI, I think I've found a bug or at least an inconsistency between code compiled with GHC and code executed by GHCi: My program calls out to native library code which uses usleep and/or nanosleep, and things work well when using the compiler. But when GHCi is used, a lot of SIGALRMs are happening, which are interrupting usleep/nanosleep (leading to EINTR). Are these signals really intended when using GHCi? If yes, what can be done to avoid them? One can argue that the library should check for EINTR after sleeping and re-sleep in that case. While it is easy and portable with nanosleep, the behaviour related to signals for usleep is explicitly unspecified, so there is not much which can be done in that case. :-( Any help is highly appreciated, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Signal inconsistency between GHC and GHCi
Am Mittwoch, 28. Dezember 2005 13:20 schrieb Sven Panne: [ usleep/nanosleep trouble deleted... ] I forgot something in my last email: -- from fptools/libraries/unix/System/Posix/Unistd.hs --- usleep :: Int - IO () usleep 0 = return () #ifdef USLEEP_RETURNS_VOID usleep usecs = c_usleep (fromIntegral usecs) #else usleep usecs = throwErrnoIfMinus1Retry_ usleep (c_usleep (fromIntegral usecs)) #endif --- Simply re-sleeping after an EINTR with the same amount of microseconds is not the right thing here, we should better use the time left. Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Space leak
Tomasz Zielonka wrote: On Tue, Dec 27, 2005 at 08:12:20PM +0100, Christian Maeder wrote: Already the following bit exhibits unexpected memory consumption: main = mapM_ print $ take (n * 5) $ drop (n * 3) [1..] n = 10 I think it's the (succ (succ (succ ...))) thunk. When you change it to [1..] there is no space leak - here every produced element must be examined before producing the next list node or []. ok, I could also fix the space leak by defining my own iterate function: myiterate :: (a - a) - a - [a] myiterate f a = a : (myiter f $! f a) main = mapM_ print $ take (n * 5) $ drop (n * 3) $ myiterate succ 1 is also ok. The next problem occurs when I try to use splitAt as in the original DNA example: main = do let (s1, s2) = splitAt (n * 3) $ myiterate succ 1 mapM_ print s1 mapM_ print $ take (n * 5) s2 The above code leaks space! But main = do let s1 = take (n * 3) $ myiterate succ 1 s2 = drop (n * 3) $ myiterate succ 1 mapM_ print s1 mapM_ print $ take (n * 5) s2 does not leak, as long as it is compiled without optimization. (Eliminating the CSE myiterate succ 1 makes it leak.) Could optimization be improved? Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
