Task & Memory stuff

[lachlan2k]

I have concerns about memory management with the way tasks are created. More specifically with RAII. When objects go out of scope, their destructor is called, for cleaning up heap memory. However, when a task is killed, the only memory stuff done by the kernel, is the stack is manually freed by PROS's task management, so I have no clue how you could actually get the destructors called.

Obviously, if you religiously follow the idea of tasks never exiting and never kill your tasks, this isn't a problem. However, if your autonomous takes longer than it should, and autonomous ends before your autonomous function exists, those destructors can't be called.

Also, when you are testing your robot, and flipping the enabled/disabled and auton/driver switches, you are constantly killing and starting tasks.

Also, more questions in regards to memory exist, with in regards to making Rust use the Kernels heap and stack. The solution for the heap seems to be custom allocators: https://doc.rust-lang.org/1.12.0/book/custom-allocators.html

I really don't know enough about how PROS influences the use of the stack and how it places memory from specific tasks on their respective TCBs, so I'll try and read some source and get some insight.

More reading on RAII in rust: https://rustbyexample.com/scope/raii.html

[HotelCalifornia]

Now that it's not 3 in the morning, I'm sort of seeing what's going on here. Basically there are two issues:

1. Rust's RAII strategy could potentially cause memory leaks as tasks are created and deleted without consulting the Rust GC
2. Rust won't be configured by default to use the stack and heap that are actually available (on the kernel side)

Problem 2 doesn't seem so hard to fix, using the custom allocator strategy.

Problem 1 has the potential of being a real issue. That being said, this thread suggests that threads can't be killed externally. This would mean (I think) that everything works out (i.e. as the thread's signal handler should handle it).

[HotelCalifornia]

I see what you're saying about the possibility of competition control causing leaks too, and I'm not sure whether that would also be handled as above