On Mon, Oct 07, 2002 at 04:59:47PM -0600, Phil Wood wrote: > Well, I just changed my code so to_ms == 0 will block as long as is > necessary. I still like to have the ability to return to the caller if > there are no packets available.
That's what non-blocking mode is for; in non-blocking mode, "pcap_read()" shouldn't wait for packets. Check whether the "nonblock" member of the "pcap_t" structure is 0 (meaning non-blocking mode isn't set) or non-zero (meaning non-blocking mode is set). > How bad would it be to use a negative > value (or just -1) to mean "if there are no packets this instant in time, > return to the calling program"? Given that there's already an API for that, it'd be bad, as programs would have to use *both* mechanisms to request non-blocking mode; it'd be better to just use non-blocking mode, as that already works on all platforms. > For what it's worth. My linux mmap'd pcap behaves as follows: > > A. With a positive timeout (initialized by the to_ms value on each call > to pcap_read), a "read" will return if either > > 1) enough polls have been called to exhaust the timeout value. > > or > > 2) the timeout expires even if no packets have been received. That's OK, but, as programs using libpcap cannot assume that when the timeout expires "pcap_read()" will return (Linux is *NOT* the only platform on which the timeout doesn't work that way - on Solaris, there's a timeout, but it doesn't work that way, so any program that assumes that the timeout can be used to limit how long "pcap_read()" etc. wait is broken on multiple platforms). > B. With a zero timeout, a "pcap_read" will never return. The timeout > is considered infinite. Of course callbacks will continue for each > packet that arrives. That's the right behavior for compatibility with other platforms. > C. With a negative value, "pcap_read" will return if either > > 1) there are no packets on the ring > > or > > 2) the packets that have been queued on the ring have all been > processed. You can do that - but you should also do it if the "nonblock" flag is set, in which case programs will just use the "nonblock" flag, so the timeout shouldn't ever be negative, so there's no point in checking for a negative timeout in that case. - 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
