lib: validate monotonicity of messages from upstream component
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 17 Jun 2019 23:18:13 +0000 (19:18 -0400)
committerPhilippe Proulx <eeppeliteloop@gmail.com>
Fri, 28 Jun 2019 20:08:01 +0000 (16:08 -0400)
commit54b135a0370e1ff40ff39515058b2f941955cd40
treed69544b2927aea1a2c7de0384f2974465d746657
parentd79a835343447b4e7f62af721cfb2a05fa9f450a
lib: validate monotonicity of messages from upstream component

This patch adds two checks after having called an iterator's next
method, to verify the validity of what is returned.

Clock class compatibility
-------------------------

Check that the clock classes of new streams created through this
iterator are compatible with the clock classes of streams previously
created through the same iterator.

The first time a stream is created through an iterator, we save some
properties of that clock class (whether its origin is the Unix epoch,
and if it isn't, its uuid).  When new streams appear, we compare those
properties to make sure the clock classes of the new streams are
compatible with those properties.

Clock snapshots increase
------------------------

Check that the clock snapshots of all messages (that have one) don't go
back in time.

For each incoming message, if it has a clock snapshot, we compare it
with the clock snapshot of the previous message and assert that it isn't
lower (the "previous message time" is initialized to INT64_MIN).

Some messages don't have a clock snapshot, for those we do nothing.

I am not considering the "infinity" value that stream activity end
messages can have.  It would add a bit more complexity to validate them
propertly, because it's possible to have something like this:

    Stream 1: ...  EV(1)       SAE(inf)  SE
    Stream 2: ...        EV(2)               EV(10) ...

As you can see, it is possible to have a finite value (10) on stream 2
after having received an SAE message at infinity on stream 1.  We could,
validate that nothing with a finite clock snapshot comes on stream 1
specifically.  It would however require some per-stream data, which adds
a bit of complexity.  And since we plan on removing these messages
anyway, it doesn't seem to be worth the effort.

Change-Id: If18f475ed056fda77a539d700e6ad310111f6d6b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1486
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
src/lib/graph/iterator.c
src/lib/graph/message/iterator.h
This page took 0.024472 seconds and 4 git commands to generate.