On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins
<g...@gregorycollins.net> 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,
<mike
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
