[Bro-Dev] Configurable &write_expire interval
jan.grashoefer at gmail.com
Sat Jun 11 06:36:45 PDT 2016
> I'd call this a bug actually. Redefs are supposed to take effect
> before anything else, so having the timeout use the original value
> here seems quite wrong.
I agree that the behavior is at least counterintuitive :)
> My immediate thought (without looking at the code) would be delaying
> evaluating the expression until the value is needed for the first
> time. At that point, the redef will have taken effect, so we should be
> fine. Essentially, we'd cache the evaluated value for the future once
> we have it.
I will have a look. If I am able to fix this I will include this in the
pull request for the intel updates.
> Serialization is an interesting question though. I believe there'd be
> nothing wrong with simply serializing the expression itself here
> (rather than its value). When deserializing, we'd restore the
> expression and make sure the cache value remains unset, so that on
> first use it will get evaluated.
Yep, meanwhile I realized serialization is already done for the
expire_func statement. In case the table is serialized having a cached
value set, it would be preferable to use this value, wouldn't it?
> In principle, we could even go further and allow a non-constant
> expression for the timeout that would get evaluated every time. My
> main concern there would be performance, although I'm not sure if that
> would actually cause much overhead in the still most common case of a
> constant (i.e., for existing scripts).
I am not sure what the actual performance impact would be. My idea would
be to cache the value in case of a constant and evaluate it every time
otherwise. That should combine the best of both approaches.
More information about the bro-dev