Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filterx scope to track message changes #467

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

bazsi
Copy link
Member

@bazsi bazsi commented Jan 23, 2025

This pull request replaces the old "log_msg_has_changes" mechanism with the recently merged generation counter.

This has the following goals/benefits:

  • it fixes a bug in message tracking, as previously we considered a message changed when it was cloned. But a message can change without being cloned.
  • we delegate the message change tracking to FilterXScope,
    • this requires that FilterXScope now has a reference to the message being processed.
    • this becomes similar to what we do with "undeclared" floating variables
    • the scope will provide a higher level interface to manage variables, moving the complexity from FilterXVariable to FilterXScope
  • it adds slight changes and makes a couple of functions inline.

@bazsi bazsi force-pushed the filterx-scope-to-track-message-changes branch 3 times, most recently from e67abf8 to 8248c38 Compare January 24, 2025 09:36
bazsi added 6 commits January 24, 2025 11:10
Previously a coupling was established between logmsg and FilterXScope,
namely whenever the LogMessage was cloned, the logmsg layer called
filterx_scope_set_log_msg_has_changes(), which was then subsequently
used for invalidating message tied variables in the scope.

This was broken for cases where the message was writable, so it changed
without being cloned. In those cases the stale variables survived anyway.

Another issue was that this produced excessive calls to the expensive
filterx_scope_invalidate_log_msg_cache(), as it may be filterx_scope_sync()
that causes the LogMessage to be cloned. In those cases we executed both
filterx_scope_sync() and an entirely unnecessary
filterx_scope_invalidate_log_msg_cache() both iterating on all
FilterXVariable instances in the scope.

This mechanism is being replaced by the generation counter mechanism, but
to make the patches easier to review, this patch just removes the entire
log_msg_has_changes() mechanism.

Signed-off-by: Balazs Scheidler <[email protected]>
…rations

Previously scope->generation was reset to 0 in case we ended up doing a
scope clone operation.

Let's retain the generation counter instead, so we don't need to adjust the
generation value for FilterXValues either.  Also, subsequent patches will
start sharing FilterXVariable instances, meaning we want to know which
generation a specific variable is associated with.

Signed-off-by: Balazs Scheidler <[email protected]>
…ocessed

I want to delegate the responsibility of tracking LogMessage changes
to the scope (just as floating values are tracked by it), and as
a preparation add a "msg" member to FilterXScope and make sure
it always contains the right message.

Signed-off-by: Balazs Scheidler <[email protected]>
@bazsi bazsi force-pushed the filterx-scope-to-track-message-changes branch 2 times, most recently from e24e1c0 to b469f95 Compare January 24, 2025 11:41
…XScope

Previously message-tied variables were managed in part within expr-variable
and in part within FilterXScope. Now with the message being available
in FilterXScope, we can delegate this in entirety to FilterXScope.

This also implements the validation of message-tied values, so if the
LogMessage changes independently from FilterXScope, we will notice that too
and consider the values of those variables stale.

Signed-off-by: Balazs Scheidler <[email protected]>
@bazsi bazsi force-pushed the filterx-scope-to-track-message-changes branch from b469f95 to cd17c54 Compare January 26, 2025 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant