Hey David, Argus gets around the reentrant problem, which is a hard lex and yacc (flex/bison) issue, by forking a filter compiler process, and passing the filter string to it. This way argus supports any number of filters, swapping them in and out as needed. While argus only does this now for its own record filter compiler, this approach does work very well for libpcap when judiciously applied, and I can highly recommend it as an approach to the list.
Carter Carter Bullard QoSient, LLC 300 E. 56th Street Suite 18K New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Guy Harris > Sent: Thursday, August 22, 2002 4:17 AM > To: David Brumley > Cc: [EMAIL PROTECTED] > Subject: Re: [tcpdump-workers] pcap_compile reentrant? > > > On Wed, Aug 21, 2002 at 05:49:54PM -0700, David Brumley wrote: > > The changelog for libpcap 0.7.1 seems to indicate that > pcap_compile is > > reentrant. > > Where? > > The changelog item for 0.6 for "pcap_compile" says: > > Fixed bug that could cause subsequent "pcap_compile()"s to fail > erroneously after one compile failed. > > but, as I remember the terms IBM used in OS/360 manuals ages > ago, that's "serially reusable", not "reentrant". (The bug > was in the way it interacted with the lexical analyzer.) > > I.e., the changelog item doesn't say that it allows two > "pcap_compile()"s to run *at the same time*, it just says > that it fixes a bug where you couldn't necessarily run it > successfully after having previously called it with an > illegal expression. (There was another bug in the 0.6 series > where using the "vlan" keyword in an expression wouldn't > cause problems with that expression but would cause problems > with subsequent expressions; that was fixed in 0.7.) > > > I tested it on a RH 7.2 box (2.4.18-5 kernel, > > glibc-2.2.5-39) and found it segfaulting about half the time when > > using pthreads. Is this a known issue? > > Well, we've never particularly committed to it being > reentrant; it's not, as it uses a pile of globals, but I > guess we never really thought about it one way or the other, > so I guess it's "known" in the sense that we didn't commit to > it being reentrant, but not "known" in the sense that its > non-reentrance was actively on our minds. > > > How much of libpcap isn't thread safe? > > I don't know (I'd have to read the source; you might want to > do so also). > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.htm> l > To > unsubscribe use > mailto:[EMAIL PROTECTED]?body=unsubscribe > > - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
