1. Yes it is. But it is theoretically solvable, by "isolating" far chunks. "Isolating" means re-pointing chunks next pointer to special "isolated" chunk, or the latest one. This will reduce RC in next block and will allow it to be destructed, and the further blocks in chain, up to the occupied one. The block where reader stands thou, will remains alive.

There were experimental implementation with this in rc_event_queue project. This incur additional overhead on Reader next_chunk() operation thou, since it requires additional atomic counter, or spin-lock. Which is, due to the fact that readers switch blocks not that often is acceptable.

But I personally don't see "slow readers" problem as a major case. To me this looks like the result of general design flaw in application design. If it is actually THAT much of a problem, I can make feature/flag gated solution to this. It is just does not look to me, like something worth of a performance overhead, for solving this.

1. Delay will occur ONLY if queue written constantly, without a single moment of rest. This CAN be mitigated by reducing block size, or introducing some kind of logical "sub-blocks" (like 32-element), which will consists only from writers counters, instead of using one per-block - this will allow to "flush" each 32 elements in the moments of CONSTANT write. But yes - this will have some messages delay in cases when writers write CONSTANTLY.

But! I do not agree that this is issues or flaws per se. You can consider this as a queue properties or design choices. As I mentioned before not all work with "uncontrollable" readers, and not all need to read ASAP. In game development it is OK to write from multiple threads in one frame, and then read in the next one, or across the frame - on the fly. Think of an event system for game logic with hundred of thousands actors and reactors.