[Snort-devel] RE: A Proposal for Reengineering Snort's Packet Matching System - Comments
tlewis at ...255...
Fri Apr 6 13:36:34 EDT 2001
On Fri, 6 Apr 2001, Fyodor wrote:
> Threads on each platform are implemented in different way, Solaris
> and BSD(?) have kernel-space threads implementation while in linux
> it is still a userland (kind of forked processes with shared memory),
> so threaded performance should differ on different systems (althrough
> interface should be the same), if that was your question.
Linux's threads are very kernel-land and is quite good, whereas most BSDs
have emulated thread support in userspace, if they have threads at all.
Digital Unix and Solaris, however, have by far the best threading
implementations, having hybrid user/kernel strategies that are so
over-engineered that they'll make your ears bleed.
> > get the impression from your response that this is not so in C. =) Is there
> > a standard threading library for C which is supported under most every OS?
> posix is supposed to be. (pthreads)
pthreads are very standardized; I don't see that we would need to use
any of the esoteric features that might lead us into potential trouble
across multiple implementations.
> > If so, what about threading the packet matching engine
> > (the part of Snort which would most benefit from this), keeping the single
> > threaded code, and allow the user (by means of the snort.conf file) to
> > choose if he has an SMP system or not?
> IMHO it might make sense to abstract from threads and design kind of
> modules spawning and message exhange protocol which could use threads,
> mpi, rpc, or corba(?) as the underlying implementation for such. That's
> the model which I am currently trying to get done on the other project
> of mine, and if it works out we may think how the similar tech could be
> applied to snort.. maybe.. :)
Well-abstracted interfaces will help a lot if you want to rpc'ify
event processing. I've already stated that I don't think that that
approach will give very good performance, but I certainly won't stand
in anyone's way if they want to try.
I think that there's consensus that making snort thread-safe is a
priority. Would anyone object to my drafting an RFC stating exactly
what this means and laying out guidelines for people's code to accomplish
tlewis at ...255...
More information about the Snort-devel