Assume that I have a linear allocator and I want to "build" a string on it. That is, I will be pushing the bytes to the allocation and change the allocation size dynamically. Now, there is a problem, what if during that process of string building someone else allocates? I see two solutions
1. Copy the string from before and continue pushing bytes.
2. Treating this situation as an error in the code. No other allocations can be made during string building.
The first solution is pretty obvious, but If there are two interleaved string builders running the waste of space can be enourmous.
The second solution is better in that it doesn't waste memory, but it forces a certain structure in the code, sometimes can be tricky to think about memory. The way to check for the error in such case would be to store some variable current_token in the allocator. Whenever a normal allocation is done it checks whether no string builder or other allocation is done (current_token == 0).
For string builder allocations, on the builder start, the allocator returns a unique token. After the string building has started only token allocations are allowed and the token must be equal to the one the string builder has given you. Then (a) no other string builder allocation can start and (b) every normal allocation will fail.
In such case it is wise to use assert to check the correctness of the token, because it is an assumption about the structure of our code. But we're coupling asserts with checking procedures that depend on runtime and in release they will execute but have no effect.
The question is whether using assert like this is a good idea (and why!) and if no what alternatives would I have