Proposal: Expand TBQueue API with 'currentSize'

David Luposchainsky dluposchainsky at googlemail.com
Thu Nov 14 23:03:35 UTC 2013


Hey everyone,


Concurrent channels are very opaque right now: all that can be done is
checking they're empty. The upcoming release will, thanks to Merijn,
contain a way of checking whether a TBQueue is full.


However, there may be scenarios where it is desirable to retrieve the
current size of a TBQueue. The reason I mention TBQueue specifically is
because it already contains said information, but does not export
corresponding accessor functions, so the implementation would be fairly
easy.


Probably the most compelling use case I can think of is debugging.
Sometimes "full" or "empty" just isn't enough: it may be useful at which
point in time the queue starts being filled disproportionately. (I just
had a case where I could have saved many hours.)


Another one inspired by someone on #haskell a couple of minutes ago is
when a "size moderated" queue is desirable, i.e. one that is usually
somewhat filled but still allows being written to in important cases.
The specific example given was a device sending data through a channel
where the input can be throttled based on how fast the output ends
process the data.


The code would be simply the following:

> lengthTBQueue :: TBQueue a -> STM Int
> lengthTBQueue (TBQueue rsize _read wsize _write) = readTVar rsize


Another possible addition would be retrieving a TBQueue's maximum size.
Although this has to be known in order to create the queue in the first
place, when the queue is used deep down in other functions passing the
size explicitly as a parameter seems a little unnecessary.


David/quchen


More information about the Libraries mailing list