What triggers GC in haskell?  We obviously aren't using Java's method of GC as needed(for good reasons, Java's method is terrible because you get slow downs when you need speed the most).  But we should be able to learn something from Java and have a gc::IO() method that one could call BEFORE a critical region of code... ---------- Původní zpráva ---------- Od: Mike Meyer Datum: 27. 11. 2012 Předmět: [Haskell-cafe] Real-time code in Haskell (Was: Can a GC delay TCP connection formation?) "On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins wrote:

If you have a hard real-time requirement then a garbage-collected language may not be appropriate for you.

This is a common meme, but frankly, it isn't true. When writing real-time code, you just need to make sure that everything that happens takes a known maximum amount of time. Then, you can sum up the maximums and verify that you do indeed finish in the real-time window of the task. GC is a problem because it's not predictable, and may not have a maximum. However, it's no worse than a modern version of the C function malloc. Some of those even do garbage collection internally before doing an OS call if they're out of memory. The solution is the same in both cases - make sure you don't do GC (or call malloc) in the critical region. Both require knowing implementation details of everything you call, but it isn't impossible, or even particularly difficult. Lazyness, on the other hand ... I haven't thought about. I suspect you need to force the evaluation of everything you're going to need before you start the critical region, but I wonder if that's enough? Has anyone out there investigated this? Thanks, http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe)"

* Mike Meyer [2012-11-27 13:40:17-0600]

Lazyness, on the other hand ... I haven't thought about. I suspect you need to force the evaluation of everything you're going to need before you start the critical region, but I wonder if that's enough? Has anyone out there investigated this?

I don't know much about RT systems, but if GC is not a problem, then laziness should be even less so. It is much more predictable, especially when you look at the Core. Roman