The oberservations / thoughts in this thread seem worth a ticket I'd
say. We can refine this over time if the current semantics aren't
quite ideal yet.
Robin
On Tue, Oct 30, 2018 at 13:17 -0700, Christian Kreibich wrote:
> Hi folks,
>
> I would agree that it takes a bit of experimentation to figure out
> exactly when a change handler fires and how to reliably initialize or
> update things based on an option's value.
>
> Consider this:
>
>module Foo;
>
>export { option foo = F; }
>
>function foo_handler(ID: string, foo_new: bool): bool
>{
>print fmt("New foo: %s", foo_new);
>
># Update stuff here based on foo's value
># ...
>
>return foo_new;
>}
>
>event bro_init() {
>Option::set_change_handler("Foo::foo", foo_handler);
>}
>
> ... foo_handler doesn't get called when you simply run the script
> without redefing Config::config_files. When you do redef it, the handler
> fires both when the config file sets foo to T, and when it sets it to F.
>
> So you have to make sure that your initialization happens even when the
> handler doesn't get called, and you cannot write your handler assuming
> that the new value is actually different from the old one.
>
> These arguably aren't bugs, but imo they do take getting used to.
>
> Best,
> -C.
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
