6 Feb
2022
6 Feb
'22
10:31 p.m.
On Sun, Feb 6, 2022 at 7:17 AM Larry McVoy <lm(a)mcvoy.com> wrote:
While I _can_ do all the malloc/free stuff myself (and
have decades of
working code to prove it), it's become harder and harder to find other
people who can.
While it's not too bad to do malloc/free in userspace in single threaded
programs, it gets harder for multi-threaded where you have multiple objects
holding references to an object you might want to free. And to get things
to run fast, you have to use increasingly sophisticated "locking" primitives
to get performance: RCU, lifetime flexibility, etc. Those methods are
hard to get right, which is why most of them include extensive run-time
proofing / asserts to try to catch leaks and other problems.
For kernel work, that adds a whole other level of complexity as well.
I'd love to have all this stuff automatically optimized and correct.
However, the state of the art for alternatives to C aren't there today
for the kernel context. While rust in Linux is a thing, it's not in the
fast path yet. Time will tell if it can grow up to do that or not, and
I'll stop there since it's a rapidly developing area and I'm sure
anything I say about the state of the art when I last looked will
be wrong in some way.
Warner