I am interested in embedded programming with rust.
As one knows so-called real-time property is one of the main concerns for product-grade programming.
"hard real-time" could not be achieved without dedicated HW. (Even if one manages to preclude context switching by manipulating the scheduler of OS, branch prediction and cache memory will produce uncertainty regarding processing time at the HW level).
Although these relatively small jitters from HW could not be eliminated, It. is quite clear that system calls are one of the major sources of uncertainty.
So, I figured out marker traits for functions indicating no system call or memory allocation. It would help to accept certain kinds of functions in a time-critical context like Fn, FnMut, FnOnce.
I would like to know if there is any apparent reason which makes the approach infeasible before I conduct a further study regarding this concept.
Yes, you are right. C would be sufficient for real-time programming, if handled by experienced SW engineer. However, wouldn't you think it relies heavily on programmer rather than systemic support?. As Rust solve memory management issue of C++, wouldn't it be helpful for less experienced SW engineers and large scale projects?