[Bro-Dev] Configurable &write_expire interval
jan.grashoefer at gmail.com
Mon Jun 13 12:41:55 PDT 2016
> Please create a separate pull request for this one first (you can
> merge it into the intel update branch, that'll be fine).
I have opened a new pull request :)
>> 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?
> It's a question of semantics: what should happen if the Bro
> unserializing it has redef'ed the constant to a different value? I
> think my intuition would expect to use that modified value after
My intuition would be that the deserialized table is identical to the
serialized one. However, this is a matter of style and shouldn't be
> Yeah, I was thinking about that too. I'd still be curious if the
> overhead of re-evaluating the constant overhead becomes noticable. If
> you're game, you could try a little benchmark just manipulating a
> table plenty times and measure if that changes execution time much.
... I did a quick measurement of the execution time for re-evaluation of
a constant and couldn't detect any performance impact. So I went for
A side note: I suspect that the table syncing did and still does not
work as reliable as one would expect. But according to Johanna this will
become deprecated soon, so I did not touch that code.
More information about the bro-dev