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

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

<snip request for while loops>