> 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. Best regards, Jan _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
