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)
committerPhilippe Proulx <eeppeliteloop@gmail.com>
Thu, 27 Jun 2019 19:06:29 +0000 (15:06 -0400)
commit5b7b55be46763e1786bb0be0e188c21e669f81b7
tree67d4227a25d2f64c7a8c571412702f7fab5671b5
parenta7facde4107f1d73771cc5e024fee173894ba921
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.026443 seconds and 4 git commands to generate.