[Bro-Dev] changing Notice::policy mechanism

[Seth Hall]

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

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/