[Snort-devel] RE: A Proposal for Reengineering Snort's Packet Matching System - Comments

Fyodor fygrave at ...1...
Fri Apr 6 13:54:35 EDT 2001


On Fri, Apr 06, 2001 at 01:36:34PM -0400, Todd Lewis wrote:
> 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

Aii.. right (just checked the kernel code/threads FAQ). I was a bit confused by
seeing each spawned thread as a separate process in process table. Frankly
speaking didn't play with threads on linux mucho.. :)

> 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.

:))

> > > 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.

yep, the only different things might be compiler switches on different platforms
to use pthreads. (on linux you have to link a library, on FreeBSD -pthread switch
is enough :))

> > 
> > 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 am just playing, not really aiming to bring it into snort for the moment
but want to get certain level of expertise in this area :))

> 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
> this goal?


Shall be posted shortly.. :) (still have that bi-i-i-g message postponed :P)

-- 
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1




More information about the Snort-devel mailing list