[Snort-devel] Thoughts on threads
nash at ...357...
Fri Apr 6 14:20:38 EDT 2001
I 2nd this emotion. Making the paengines and the decoders as fast as possible
in code (w/out threads) makes good sense. Adding the other functions as threads
that might run slower seems very appropriate. Plus, the pitfalls of such a
producer / consumer model are fairly well known and there's lots of good example
code. Mmm ... maybe I'm just lazy. ;-)
In response to Fyodor's suggestion in regards profiling. Well, it just seems
like optimizing for the special case and that seems like a dubious idea.
On Fri, Apr 06, 2001 at 02:00:10PM -0400, Jon Bentley wrote:
> I haven't received a good beating recently, so I'll through my two cents
> into the ring.
> Threads (nee parallelization) would cause me some concern, as it would
> potentially remove the serial order of received packets. Perhaps that is
> a concern of only myself, though. (Packet sequence numbers, with a post-
> process reordering?)
> I'd rather see a thread dedicated to an atomic task, rather than full
> execution. This gives the ability to buffer individual task results, and so
> basic prioritization among tasks. (To wit, if a single thread processes
> aspect of a packet, and I get hit with a burst of packets, I'm going to lose
> However, if the front-end task merely traps and buffers packets, with a
> priority thread doing post-processing, then bursts are no problem.)
> Pthreads are great, but do we care about our W*ndows friends?
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
"Babbage himself acknowledged Jacquard's precedence: when
he presented the concept for his Analytical Engine at the
Turin conference, he brought with him a silk portrait of
Jacquard that had been produced by an automatic loom
programmed by no fewer than twenty-four thousand cards.
Even by today's standards, that's a lot of code."
- Jim Holt,
The New Yorker 2001/3/5
More information about the Snort-devel