"for and while" in Bro language (and threading?)
vern at icir.org
Sun Jul 13 12:03:20 PDT 2003
> 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
> 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
> 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?
More information about the Bro