[Bro-Dev] Configurable &write_expire interval

Jan Grashöfer 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.

Best regards,
Jan


More information about the bro-dev mailing list