lib: fully configure graph (add components, connect ports), then run
authorPhilippe Proulx <eeppeliteloop@gmail.com>
Thu, 20 Dec 2018 13:40:39 +0000 (08:40 -0500)
committerFrancis Deslauriers <francis.deslauriers@efficios.com>
Thu, 2 May 2019 20:50:15 +0000 (20:50 +0000)
commit4725a2013cb518374822ccb490610b45f74dbdbf
tree7e19d75f0cb67b1aa8d26aa0975e61b41833553e
parent13d428598c645803f8745b6db2c6dc2cde5e33c4
lib: fully configure graph (add components, connect ports), then run

This patch makes the graph API force you to completely configure the
graph, that is, add components and connect their ports, before you run
it. When you run it, the graph is considered fully configured, and at
this point you cannot add components or connect ports.

This also means that components cannot remove or disconnect their own
ports anymore. Therefore all the disconnection and port removal
listeners and notifiers are removed.

The purpose of this change is to make seeking possible for all message
iterators. If a component can remove and add ports at will, considering
that message iterators are completely independent, then seeking
backwards is impossible without a scandalous hack because some message
iterators are gone for good and cannot be created again since the ports
do not exist anymore.

This change implies that a `src.ctf.lttng-live` component will need to
merge its messages itself to offer a single port on which you can create
a single message iterator. If the LTTng live protocol supports seeking
in the future, then, with a single port, the message iterator has total
control to recreate old messages which belong to already ended streams.
Note that this could apply to other, similar component classes as well.

Offering a single stream per port is possible when the number of streams
is known at component initialization time, which is the case for
`src.ctf.fs`.

`flt.utils.muxer` still adds a new input port on port connection, but
this is all done before we call bt_graph_run(), which marks the graph as
being completely configured.

An output port message iterator marks its graph as being configured
as soon as you call bt_port_output_message_iterator_next(), because you
don't call bt_graph_run() in this situation.

A graph's "configured" state is only set and checked in developer mode.
New preconditions are:

bt_self_component_port_input_message_iterator_next():
    The graph is fully configured.

bt_graph_add_source_component():
bt_graph_add_source_component_with_init_method_data():
bt_graph_add_filter_component():
bt_graph_add_filter_component_with_init_method_data():
bt_graph_add_sink_component():
bt_graph_add_sink_component_with_init_method_data():
bt_graph_connect_ports():
bt_self_component_source_add_output_port():
bt_self_component_filter_add_output_port():
bt_self_component_filter_add_input_port():
bt_self_component_sink_add_input_port():
    The graph is not fully configured.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
21 files changed:
include/babeltrace/graph/component-class-filter.h
include/babeltrace/graph/component-class-internal.h
include/babeltrace/graph/component-class-sink.h
include/babeltrace/graph/component-class-source.h
include/babeltrace/graph/component-internal.h
include/babeltrace/graph/connection-internal.h
include/babeltrace/graph/graph-internal.h
include/babeltrace/graph/graph.h
include/babeltrace/graph/self-component-port.h
include/babeltrace/plugin/plugin-dev.h
lib/graph/component-class.c
lib/graph/component.c
lib/graph/connection.c
lib/graph/graph.c
lib/graph/iterator.c
lib/graph/port.c
lib/plugin/plugin-so.c
plugins/utils/muxer/muxer.c
plugins/utils/muxer/muxer.h
plugins/utils/plugin.c
tests/lib/test_graph_topo.c
This page took 0.028378 seconds and 4 git commands to generate.