From: Philippe Proulx <eeppeliteloop@gmail.com>
Date: Sat, 20 Jul 2019 21:16:24 +0000 (-0400)
Subject: lib: create input port msg iterator from self {msg iterator, sink comp.}
X-Git-Url: http://git.efficios.com/?a=commitdiff_plain;h=ca02df0ad8ae9a1a3640956d91ca31059d0b203a;hp=ca02df0ad8ae9a1a3640956d91ca31059d0b203a;p=babeltrace.git

lib: create input port msg iterator from self {msg iterator, sink comp.}

This patch makes an input port message iterator have a link to the
upstream message iterators it needs and vice versa.

The motivation behind this is to eventually be able to transmit some
state or property automatically to all the upstream message iterators,
recursively, of a given message iterator without any special user code.

For example, consider this graph of message iterators (arrow means "is
an upstream message iterator of"):

    A <──┐
         ├──┬── C <──┬── F
    B <──┘  │        │
            │   E <──┘
    D <─────┘

                G <───── H

Here, setting the state/property on F would also set it on A, B, D, C,
and E. Setting it on C would set it on A, B, and D. Setting it on H
would only set it on G.

The message iterator graph, which can be considered like another,
"dynamic" graph on top of the static component graph used only to limit
a message iterator graph's topology, is always directed and acyclic,
where each node has a single parent. In other words, it is not permitted
that two message iterators use the same downstream message iterator, for
example:

    A <──┐
         ├───── C <───── F
    B <──┘      │        │
                │        │
    D <─────────┴────────┘

(D has both C and F as parents).

This is so that each message iterator and its upstream message iterators
constitute a single, private state.

This patch replaces
bt_self_component_port_input_message_iterator_create() with
bt_self_component_port_input_message_iterator_create_from_message_iterator()
and
bt_self_component_port_input_message_iterator_create_from_sink_component().

bt_self_component_port_input_message_iterator_create_from_sink_component()
does nothing with the self sink component parameter (except checking
that it's not `NULL`), but it's needed to make the functions type safe.

Internally, an input port message iterator contains both a weak pointer
to its downstream message iterator and an array of weak pointers to its
upstream message iterators.

When you create a message iterator with
bt_self_component_port_input_message_iterator_create_from_message_iterator(),
the function sets the new message iterator's downstream message iterator
to the provided self message iterator. It also adds the new message
iterator to the self message iterator's array of upstream message
iterators.

On message iterator finalization:

* The message iterator removes itself as the downstream message iterator
  of all its upstream message iterators. It also clears the upstream
  message iterator array.

* The message iterator removes itself as one of the upstream message
  iterators of its downstream message iterator.

I didn't find any race condition regarding the new message iterator
links, but I could be wrong. The future and more tests will tell us.

In the `bt2` Python package:

* _UserComponentInputPort.create_message_iterator() is removed.

* _UserMessageIterator._create_input_port_message_iterator() is added
  (accepts a user component input port).

* _UserSinkComponent._create_input_port_message_iterator() is added
  (accepts a user component input port).

Tests are updated accordingly.

I added a test for
_UserMessageIterator._create_input_port_message_iterator() specifically
(needs a filter message iterator) because we use
_UserSinkComponent._create_input_port_message_iterator() in the current
tests.

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