oneapi-src
Mark all non-virtual methods from receiver class template as virtual
In some cases it is convenient to build a single node type (sender/receiver) which is composed of multiple other nodes (e.g. function node with bounded queueing policy, which requires limiter and function nodes to be combined). In this case it is beneficial to forward calls to public receiver class methods to some other node, but in order to do that, those methods must be marked as virtual. This PR marks all receiver class template methods as such.
Hi @Jauler , thanks for the PR!
Usually, composite_node is used for combining multiple nodes together to form a subgraph. Could you please describe your preference against composite_node?
Well I have a few cases:
- input
- some internal processing nodes
- output
Internal processing nodes are the simplest ones, therefore I described them in my original message, and yes, these are covered well by composite_node I should have read documentation more rigorously and should have described all of the cases.
We are trying to build stream processing graph, therefore sometimes it will have to sit idle waiting for input and sometimes input might come faster than graph can process it, so we used out-of-tbb thread for reading input (and sending output), but we need some flow-control. TBB message passing protocol seems perfect for this, basically pulling from input thread when input is coming faster than we can process it (but thread must be blocked if too many messages are accumulating). And pushing if input is scarce. This way we would be able to avoid some busy-waiting, unecessary sleeping, or calling try_put()/try_get() just for it to return false too much. To implement this - deriving from sender<T> seemed the way to go. But I might be missing something here...
Output is basically the same, just a mirror image of the input, therefore we required both, sender<T> and receiver<T> to be virtual.
@Jauler, could you please retarget the PR to the master branch, if it is still applicable for oneTBB latest version.
Hi,
Unfortunately, I have no access to the original case. But I remember I was unable to extend the receiver class due to it having non-virtual methods.
Therefore the current update is best-effort to remember what was needed to be done, and then applying that to master. It seems like two try_put() specializations are gone, therefore the only change left is the method declaration itself. Should be rather safe change. Tests seems to be passing too.
Note: there is also multifunction_output class template which also seems to have non-virtual try_put() method, the same as receiver template, in both 2019 version and current master. If someone may need to extend that class, one might encounter the same problem. But as this is not part of original changes, I would like to avoid changing things unnecessarily without having more in-depth context.