"for and while" in Bro language (and threading?)

[Vern Paxson]

> Either one, or both, would be extremely useful as far as I can see. I
> suppose there are reasons that these are not included, and it would be
> good to know those reasons. I assume that it is so that someone can't
> blow a hole in their foot, since if one doesn't do bounds checks, Bro
> would probably freak out.

It's not bounds checking, it's the possibility of spending a great deal
of time in a single function or event handler, which can lead to packet
drops.

> It would be nice if the actual bro pieces were threaded for various
> reasons. I'd assume that if it were a completely threaded app that the
> crashing behavior it seems to exhibit during load, the packet dropping,
> and other aspects could be seriously improved.

It might help, but it would also introduce a whole set of nasty-to-debug
race conditions.  I want to avoid those if at all possible.

(Note, you can effect a degree of multi-threading by using events for
control flow.)

> Certainly to split off the BPF code into a spearate thread would
> allow it to read on ahead and not loose as much network traffic on a
> busy network

BPF already runs in a separate thread, namely the kernel, so there's no
further gain to be had here.

> while the actual parser/analyzers could be chugging along
> merrily in another (or other) thread/s.

There might indeed be a gain here.  It would depend in part on how much
data structure locking is required.

> Anyone have the reasons that there is no for or while loops?

Per the above.

> And, what
> should be substituted in their place?

In what contexts do you find you need them?

		Vern