3 iulie 2012 18:27
As I understand it, if you set BoundedCapacity of a TransformManyBlock, it limits the total number of items in the incoming queue, being processed and in the outgoing queue. If the number of those items is over the capacity, no new items are accepted into the incoming queue. But even then, items from the incoming queue are still being processed.
This seems like a weird behavior to me. What I would expect is that if the block is over the capacity, it won't process its input queue, so that it doesn't get even more over the capacity.
For a more concrete example, imagine I have a TransformManyBlock that produces 100 expensive objects for each incoming item. I don't want to produce too many of them at once, so I set its BoundedCapacity to 100. But if the timing is such that 100 items are received before the first one of them is processed, you soon end up with 10000 expensive objects waiting in a queue. On the other hand, if things were as I first expected, you could be sure there won't be more than 200 of the expensive objects waiting.
I could achieve the behavior I want by encapsulating ActionBlock with the capacity of 1 and a BufferBlock with the capacity of 100, where the ActionBlock would SendAsync its results to the BufferBlock. But I feel like this behavior could be the default for TransformManyBlock. Why isn't it? Or maybe it would be better if the capacity of each queue could be set separately?
6 iulie 2012 00:02Proprietar
It's like this because of the typical scenarios we saw for TransformManyBlock. Most of the cases were about decomposing the input into the output, e.g. getting a T as input and having the output just be all of the T elements contained in that array (potentially with some minimal transformation over each). In a scenario like yours, if the resource consumption between the input type and the output type is drastically different, then you can certainly encapsulate an ActionBlock and BufferBlock as you say, with a different capacity set for each.