On Thu, Jan 17, 2002 at 10:14:47AM +0100, Yoann Vandoorselaere wrote:
> > > I tryed a simple workaround, when there is only one interface to listen
> > > on (most of the case), which is to call pcap_loop() with a cnt of -1.
> > >
> > > Someone tested the workaround on FreeBSD 5.0, and it seem we're still
> > > getting burst of packet.
> >
> > Did you put the devices into non-blocking mode?
>
> I didn't, because AFAIK, the bug is concerning poll() and not read(),
The non-blocking mode is part of the workaround for the "poll()" bug -
the problem is that if you get a timeout from the select, and then try
to read from a BPF device, the read will block until either
1) the BPF timeout expires
or
2) the buffer fills up
and the BPF timeout starts when the *read* is done, so you'll still
block if the buffer isn't full.
> but I suspect libc_r to make use of poll() when doing a read().
If you're using the thread library, I don't think the "select()" timeout
workaround will help; the thread library will expect "poll()" to work
correctly on BPF devices, so a thread blocking on a read from a BPF
device won't unblock until the buffer fills up.
-
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
