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
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,