Skip to content(if available)orjump to list(if available)

RealtimeSanitizer for Rust

RealtimeSanitizer for Rust

16 comments

·January 21, 2025

jtwaleson

Ok so basically they are introducing annotations so that the compiler can reason about the code and warn the programmer for non-realtime usage.

When you think about it, it's a lot like a type system.

I haven't worked with realtime systems, but I have other constraints. E.g. I want the memory usage of a function to stay within x kilobytes, or I want an api call to return within a second, or I want to ensure there is no PII being sent to the logs.

I sincerely hope that in the future we'll have languages that cater to these kind of constraints. Think function coloring on steroids. This way the compiler can help figure out problems and we need way less tests.

Sharlin

Resource (including time) use is a type of (side) effect, and when effects are modeled at type system level we talk about effect systems[0]. There's definitely quite a bit of interest in effects among the programming language design/theory crowd.

[0]: https://en.wikipedia.org/wiki/Effect_system

dymk

It's not like a static type system, and the compiler isn't doing any new reasoning about the code with the sanitizer enabled. It's all runtime checks.

ssfrr

The underlying clang featurs support compile-time checks as well via the Performance Constraints system: https://conference.audio.dev/session/2024/llvms-real-time-sa...

actionfromafar

It feels like a lot of such constraints should be possible already in some languages...

jtwaleson

Interesting! Do you have examples of what you have in mind?

actionfromafar

I only have grug brain, but one could call WASM modules each with its own tiny memory pre-allocated. There is also WUFFS the language which is explicitly limited in several ways. I also feel like some things could be done in Ada or one of the more strict functional languages.

0: https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang...

kibwen

Most languages don't offer the ability to arbitrarily grow the stack, so it should be straightforward to compute an upper bound on any given function's stack usage. C is a bit harder, you need to forbid alloca, as well as goto and setjmp/longjmp (because I think you need to ensure that control flow is reducible in order to do this analysis).

But the problem then is that the existence of recursion in every language means that even if you know the size of every function's stack, you can still have an arbitrary amount of stack usage due to recursive function calls, so you need to forbid recursion as well.

And that only gives you guarantees WRT to the stack, so you'll probably also want to forbid general heap allocations (possibly replacing them with some fixed-size static buffers).

nevi-me

This looks like it could also be useful in embedded programming, specifically around detecting allocations in platforms that allow them.

Rygian

The remark on flagging mutex use was quite interesting. From afar, using mutexes in real-time code seems like asking for ~trouble~ formal validation.

oytis

Oh, I hoped it would be able to check timing constraints. In reality it's a linter marking known bad function calls.

saagarjha

Does this flag loops as well?

AlotOfReading

No, it's basically just function coloring. Useful, but very limited in what it can detect.