Right -- and what are we smoking today? First off, a minor issue - we only perform the select from a single thread. No matter...
Seriously, select() works in every other Unix and Unix like OS, and in non-Unix OSes like Win32... I can go to freshmeat or SoureForge and find 100+ web servers and similar projects, pull them down and see the same basic construct ntop uses. I'm starting from a position of not being really happy with something one-os specific. I suppose it's possible to ifdef this in, but what is "it"? AFAIK it's minimally documented... beyond the man page - which doesn't say what the filters are for example, a tcp/ip request received on one of two open sockets - has anyone actually seen an example of kqueue() code we could crib from? Stanley, since the --set-pcap-nonblock seems to work (or are you having problems with it?), let's table this until 3.0 releases... -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Stanley Hopcroft > Sent: Wednesday, February 04, 2004 7:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop-dev] [PATCH] FreeBSD hangs in daemon mode > > > Dear Gentlemen, > > Perhaps this letter from Mr Dmitry Mark may shed some light on this > matter, > > > SH> I beg your pardon for this unsolicited letter asking for help about > a > SH> matter in which you may be able to contribute. > SH> > SH> I refer to your letter > SH> > SH> > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2003-09/0124.html > SH> > SH> about problems with select() on bpf fds on FreeBSD 4.x systems > (please > SH> forgive my use of words I don't properly understand). > > this was pilot error, I did not set up nfds select() parameter > correctly. > > SH> The ntop project (http://www.Ntop.ORG) is a multi-threaded packet > SH> capture and accounting facility (with RRD persistence and a spiffy > web > SH> interface). > SH> > SH> Recent CVS editions hang in a state reported by top as bpf. > SH> > SH> This sounds like the problem you reported since the ntop coders tell > me > SH> that the ntop threads use select() on bpf fds. > > I'm not sure select is thread-safe. Unless you are create explicit > thread with select() loop in it. > > However, on relatively recent versions of FreeBSD you'd better use > kqueue(), as you can see in -hackers archive, which is exactly O(1) and > thus is the most effective. > > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** > > 4.x versions have had the kqueue() function since about 2000. > > >From the man page, > > KQUEUE(2) FreeBSD System Calls Manual > KQUEUE(2) > > NAME > kqueue, kevent -- kernel event notification mechanism > > LIBRARY > Standard C Library (libc, -lc) > > SYNOPSIS > #include <sys/types.h> > #include <sys/event.h> > #include <sys/time.h> > > int > kqueue(void); > > int > kevent(int kq, const struct kevent *changelist, int nchanges, > struct kevent *eventlist, int nevents, > const struct timespec *timeout); > > EV_SET(&kev, ident, filter, flags, fflags, data, udata); > > DESCRIPTION > kqueue() provides a generic method of notifying the user when an > event > happens or a condition holds, based on the results of small pieces > of > kernel code termed filters. A kevent is identified by the (ident, > fil- > ter) pair; there may only be one unique kevent per kqueue. > > The filter is executed upon the initial registration of a kevent in > order > to detect whether a preexisting condition is present, and is also > exe- > cuted whenever an event is passed to the filter for evaluation. If > the > filter determines that the condition should be reported, then the > kevent > is placed on the kqueue for the user to retrieve. > > The filter is also run when the user attempts to retrieve the > kevent from > the kqueue. If the filter indicates that the condition that > triggered > the event no longer holds, the kevent is removed from the kqueue > and is > not returned. > > Multiple events which trigger the filter do not result in multiple > kevents being placed on the kqueue; instead, the filter will > aggregate > the events into a single struct kevent. Calling close() on a file > descriptor will remove any kevents that reference the descriptor. > > kqueue() creates a new kernel event queue and returns a descriptor. > The > queue is not inherited by a child created with fork(2). However, > if > rfork(2) is called without the RFFDG flag, then the descriptor > table is > shared, which will allow sharing of the kqueue between two > processes. > > > Yours sincerely. > > -- > ------------------------------------------------------------------------ > Stanley Hopcroft > ------------------------------------------------------------------------ > > '...No man is an island, entire of itself; every man is a piece of the > continent, a part of the main. If a clod be washed away by the sea, > Europe is the less, as well as if a promontory were, as well as if a > manor of thy friend's or of thine own were. Any man's death diminishes > me, because I am involved in mankind; and therefore never send to know > for whom the bell tolls; it tolls for thee...' > > from Meditation 17, J Donne. > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
