The particular problem you're referring to is fixed if you compile all your libraries with -falways-yield; see http://hackage.haskell.org/trac/ghc/ticket/367
I believe that it is possible to give a guarantee that the kill signal will hit the thread in a timely fashion. The obvious gap in our coverage at the moment is that there may be some primops that infinite loop, and there are probably other bugs, but I do not believe they are insurmountable. Edward Excerpts from Gwern Branwen's message of Fri Mar 15 14:39:50 -0700 2013: > On Fri, Mar 15, 2013 at 5:17 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > > There is a lot of subtlety in this space, largely derived from the > > complexity of interpreting GHC's current profiling information. Your > > questions, comments and suggestions are greatly appreciated! > > How secure is this? One of the reasons for forking a process and then > killing it after a timeout in lambdabot/mueval is because a thread can > apparently block the GC from running with a tight enough loop and the > normal in-GHC method of killing threads doesn't work. Can one > simultaneously in a thread allocate ever more memory and suppress kill > signals? > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
