lib: add logic in auto-seek to recreate stream state
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 17 Jun 2019 16:58:31 +0000 (12:58 -0400)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 18 Jul 2019 15:53:33 +0000 (11:53 -0400)
commit143feff5b3233146561dd4d2fa85c497f60e801c
tree318946cb77dd8a5444bd8ce757a9d34383a97bec
parent85f32e4f50e5c0008d5012ba57c48cbdd6181664
lib: add logic in auto-seek to recreate stream state

The trimmer component uses the seek_ns_from_origin iterator method to
seek its input iterator to the beginning of its trim window.  After,
that, it's possible for the first message after the seek time to be, for
example, an event message.  If so, it needs to re-create some messages
(possibly stream begin, stream activity begin and packet begin) to put
the stream in the right state.  Otherwise, it would emit messages in an
invalid sequence.

A problem arises however with the following sequence:

1. The trim window starts at timestamp 50
2. Trimmer gets event message with timestamp 100 on stream 0. The
   trimmer will send the following messages: stream 0 beginning, stream
   0 activity beginning at timestamp 50, packet beginning message on
   stream 0 at timestamp 50, event message on stream 0 at timestamp 100.
3. Trimmer gets event message with timestamp 120 on stream 1. The
   trimmer will send the following messages: stream 1 beginning, stream
   1 activity beginning at timestamp 50, packet beginning message on
   stream 0 at timestamp 50, event message on stream 1 at timestamp 120.

The "stream 1 activity beginning at timestamp 50" message is invalid,
because it is earlier than the previously sent message "event message on
stream 0 at timestamp 100".

To avoid this going back in time, we need to emit the made up messages
first thing after seeking, instead of waiting for an event message (or
some other message requiring a stream and/or packet to be open) to emit
them.  The trimmer can't do that itself, because it doesn't know the
state of the streams right after seeking (it doesn't know what messages
would have come before the seek point).

Therefore, the patch moves the functionality of emitting the missing
messages to the iterator code.  When seeking (and using the go to
beginning then fast forward strategy, AKA auto-seek), the iterator code
goes through (and drops) all messages before the seek point.  It can
therefore maintain a table of the state of all the streams.  Once it has
reached the seek time, it can generate the messages required to bring
the streams in the state they are supposed to be, before transmitting
the messages coming from upstream.

Moving this functionality to the iterator also has the advantage that if
other components use the seek_ns_from_origin method of the iterator,
they'll receive a valid flow of messages.  They won't need to do the
same complex work that the trimmer was doing to try re-create messages.

Since the trimmer can now assume a valid message flow from its input
iterator, it doesn't need anymore to generate its own stream beginning,
stream activity beginning and packet beginning messages before
transmitting a message that is supposed to come after one of these.
This means that the ensure_stream_state_is_inited and
ensure_cur_packet_exists functions can be removed.

Change-Id: I548f6ceafa5ad315c65be48077898595882e4511
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1450
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
src/lib/graph/iterator.c
src/plugins/utils/trimmer/trimmer.c
This page took 0.02571 seconds and 4 git commands to generate.