[Bro-Dev] changing Notice::policy mechanism

Seth Hall seth at icir.org
Fri Nov 2 09:51:24 PDT 2012

On Nov 2, 2012, at 12:38 PM, Robin Sommer <robin at icir.org> wrote:

>   - (1): That's the "synchronous" part. There's actually nothing
>    internally that would prevent us from executing event handlers
>    immediately, rather than queuing them first. In some sense, they
>    would jump to the head of the queue and be processed immediately.
>    We could indeed introduce a new attribute for such events, though
>    I'm not sure I like &synchronous (but no better idea right now).

I don't like that attribute either.

>        event foo()
>        {
>           [...]
>           event stop; # No further handlers for this event.
>        }

I actually don't like this.  I like to be able to assume that all event handlers will execute and I can see users causing some major debugging headaches for us with it.

> (3) is tricky though, not sure how to do that without return values?
> Question is: can we do without? We don't need it for actions (they can
> just turn into function calls), but what about suppress-for style
> stuff. Seth, you said that suppress_for is not a problem either?

Correct, suppress_for isn't a problem and I don't think we need (3) anyway.  

What about my proposal I sent out a little bit ago?  Make a third type of code block with all of the characteristics that we want?  We don't have to compromise on existing and good designs for functions or events that way.


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list