Mcnts (m-counts) are the moving force in this processing pipeline. As packets are received from the network the net thread processes them and determines where they go in shared memory based on the mcnt in the packet header.
The old processing logic in the net thread did not handle late packets very well and as a result we would get pipeline hangs or lockups where threads were waiting on each other to fill and free blocks. In this case the net thread would become stuck in a logic flow control loop because we had no logic to handle late packets and re-initialize the buffer when we feel sufficiently behind.
Our logic was sensitive to any sort of processing jitter in all of the processes (and OS and kernel tasks) and so when any process took longer than normal before the net thread was able to execute again the net thread would fall behind. So these changes make the net thread more reliable and robust despite these forces. Meaning that other issues (RTBF taking a long time or virtual memory dump issue in the kernel) are still happening but we don't hang because this new logic detects this and re-inits the pipeline (i.e., some loss of data).
In the brief testing we have done with these changes it seems that the goal is largely accomplished but there are yet more changes and improvements that can be made to the pipeline. For example, we are still only using 4 input blocks on the net thread and ping-ponging back and forth (e.g., actively fill 2 while 2 are being emptied) and we could write better code that utilizes the ring buffer structure more effectively.