yesmar / rm Goto Github PK

The code works, but needs a proper test harness and set of end-to-end tests.

I like the idea of this system, but the fact that it uses on calloc/realloc is a real drawback. Heap operations are slow. Given the fact that rm is used to track a stack of resource frames within the scope of a call, using the stack seems like a better idea. The real benefit of using the heap is the ability to arbitrarily grow the size of the stack of resource frames. That's not really a need of rm. Functions typically have a finitely small number of resources that need to be tracked. The number is typically known at compile time and doesn't change dynamically. Hence, the primary benefit of the current heap implementation is not needed. This seems like a perfect use case for C99's variable length arrays. We know the number of resources to be tracked at compile time so we can initialize the stack as a VLA with that as its maxsize property. (See Wikipedia for details.)

Yes, it works. Yes, it is suboptimal. Replace for with while that relies on rm_pop to do the right thing.

Well, duh.

Alexey Kutepov's implementation has API for replacing and getting rid of frames within the stack. This is a total violation of the classical stack ADT, but is completely necessary because of the variable nature of resource management requirements within a function. It is unrealistic to impose full stack unwinding on functions because they may need to deallocate things in a specific order under certain situations. Therefore, my implementation needs the ability to flexibly replace a resource while preserving its encapsulating frame. Given this requirement, it possibly makes better sense to select a different ADT, such as a red-black tree. That would add more complexity than is actually required. My functions typically track less than half a dozen resources, so a stack is acceptable.

Just like the resource management stack has a rm_replace function, it needs an rm_delete function. rm_replace swaps one resource for another while preserving the containing resource frame, which is fine. But sometimes we simply need to deallocate a resource, closing any gap in the stack.

I want to repurpose rm_free for a new API to deallocate a caller-specified resource. That means I need to rename the existing rm_free function.

Let's go with the MIT license for this one…