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)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Fri, 3 May 2019 22:19:37 +0000 (18:19 -0400)
commit9cce94e4ca1b5c103f43d4b0d7c9aa7909300105
tree0194db42ed5ac62995cc9cb208895f1ddb30801d
parent4fad6649d385de19fa55a01a7d24401021363dd1
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.027519 seconds and 4 git commands to generate.