lib: remove output port message iterator
authorPhilippe Proulx <eeppeliteloop@gmail.com>
Sun, 4 Aug 2019 14:04:03 +0000 (10:04 -0400)
committerPhilippe Proulx <eeppeliteloop@gmail.com>
Mon, 5 Aug 2019 19:10:13 +0000 (15:10 -0400)
The output port message iterator concept was not a good idea in the
beginning: it breaks the graph model, making it possible to iterate a
disconnected output port (which is weird from the component's
perspective), blocking the graph (user cannot call bt_graph_run()), and
forcing the graph not to contain any sink component. This looks and
feels like a hack.

For the C part, a subsequent patch should implement an easy way to add a
simple sink component to a graph based on a simple callback and custom
user data instead of going through the inconvenience of creating a sink
component class, setting the methods manually, creating an input port
message iterator once the graph is configured, etc.

For the Python part, we'll focus on `TraceCollectionMessageIterator` to
replace `_OutputPortMessageIterator`. `TraceCollectionMessageIterator`
should cover most of the use cases and is easier to use: you don't need
to set up your graph, add your own `flt.utils.muxer`, etc.

For more advanced use cases in Python, it's always possible to create a
"proxy sink component", just like `TraceCollectionMessageIterator` does
internally, to get full control on the input port message iterator.

To adapt the current tests, `TestOutputPortMessageIterator` in
`utils.py` can be used like an output port message iterator. Such an
iterator cannot seek however, so `test_message_iterator.py` needed
special treatments to make the eventual input port message iterator
seek.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I92d432fb33d35ae3c0262b723cdfeae82c6633c9
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1821
Tested-by: jenkins <jenkins@lttng.org>

No differences found
This page took 0.024702 seconds and 4 git commands to generate.