ENOSIG Discussie (threads)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

For what is OCaml NOT suitable


Joost asked yesterday if there was a class of problems for which OCaml
was NOT good. Basically, I answered "writing UNIX kernels and device
drivers", but there is another class I forgot about: Any program where
you must guarantee some sort of latency, you cannot write in OCaml.

This includes large fields of use, like plane autopilots, car breaks
control systems, car "anti-slippery" electronics, but also real-time
transformations on music or video.

Why is that? Because of the garbage collector. It can run anytime, for
an unpredictable amount of time. Making you miss your latency
deadline. (Obviously, if your hardware is anything like our current
desktop machines, not smallish embedded hardware, and your latency is
3 seconds, not 2ms, then I guess you can be pretty sure the garbage
collector won't interfere too much) And crash in the tree on the
border of the road. Or have your user hear a hiccup in the
music. Maybe for not too hard deadlines, you can get away with
"preemptively" calling the GC by hand at a moment where it is good for
you, so that it doesn't run when you can't afford it. Maybe.


Note this applies to any programming with a garbage collector: Java,
C/C++ with a GC library, ...


Here, I must say that the GC is a pretty good one, though. It's by far
not feeling as on a HP48 (the machine freezes while a full cycle is
done, very long thus): The GC runs by "slice", somewhat widespread
over the lifetime of the program.

<<inline: application/pgp-signature>>



[ Date Index] [ Thread Index]