Even though the count is done on the consumer side which should always underestimate the real count, the number of estimated enqueued item in the MPSC channel can be negative.
See #48 (comment) and CI https://dev.azure.com/numforge/Weave/_build/results?buildId=25&view=logs
This is not blocking as this count is only informative and used for adaptative stealing and for the memory pool to trigger batch reception of memory.
This is something I actualy remarked in the past but seems to happen rarely:
|
func peek*(chan: var ChannelMpscUnboundedBatch): int32 {.inline.} = |
|
## Estimates the number of items pending in the channel |
|
## - If called by the consumer the true number might be more |
|
## due to producers adding items concurrently. |
|
## - If called by a producer the true number is undefined |
|
## as other producers also add items concurrently and |
|
## the consumer removes them concurrently. |
|
## |
|
## This is a non-locking operation. |
|
result = int32 chan.count.load(moAcquire) |
|
|
|
# For the consumer it's always positive or zero |
|
postCondition: result >= 0 # TODO somehow it can be -1 |
Even though the count is done on the consumer side which should always underestimate the real count, the number of estimated enqueued item in the MPSC channel can be negative.
See #48 (comment) and CI https://dev.azure.com/numforge/Weave/_build/results?buildId=25&view=logs
This is not blocking as this count is only informative and used for adaptative stealing and for the memory pool to trigger batch reception of memory.
This is something I actualy remarked in the past but seems to happen rarely:
weave/weave/channels/channels_mpsc_unbounded_batch.nim
Lines 208 to 220 in fffffd1