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