Replying to the update only at this time:

It would be handy to have ...

• length() -- The module already has method n().

• max_length() -- You supplied this information to me at creation time.

  It never changes. If you need it, remember it.

• is_full() -- Show me a use-case?

  One that doesn't involve you polling this method to decide when to push a new value.

  That polling will require the queue to be locked while the value is calculated, and unlocked prior to returning the value to you. That polling will slow down every other producer and consumer. And the value returned will be out of date by the time you get it.

  Therefore there could be no guarantee that if it returns not-full, and you immediate nq(), that it won't block. The information is therefore useless to you.

  Conversely, if you just go ahead and nq(), and it needs to block, it will, and will consume no cpu until the OS wakes it when room is available. (Via cond_signal).

  I doubt you will ever find a realistic use case that will persuade me to add this.

• peek() -- Again, you could try to convince me with a use-case, but you are unlikely to succeed.

  By the time pq() returned the next value to you, some other thread may have dq()'s it. Then what?

• peek_all -- There is no possible use-case for this.

  There already is the private method: _state() which effectively does this. It returns the entire internal structure as a string.

  Its intended use is a debugging aid. Indeed, I added it to allow me to track down a timing issue. But even then, for it to be useful, I had to serialise all state transitions, to make it a usable diagnostic. And doing that, by necessity, slowed the throughput to a crawl.

Not only would the above make the module more testable, they'd also make it more useful.

Sorry, but I disagree completely with both halves of that statement.

A queue has one purpose in life. Take things in at one end and let them out at the other as efficiently as possible.

Compromising the function to make testing easier is not going to happen. Adding could-dos without use-cases, for their own sake, is not going to happen.