> How about adding a pcap_is_packet_waiting() which will perform the test > for you. > The app would call pcap_dispatch() only if > pcap_is_packet_waiting() returns true, and the app can get on with other > things on false. > Arguments could be a pcap_t struct, and perhaps a timeout in > microsecs. It seems that a select()/poll() based test would work on most > systems, so surely this provides a platform-independent way to test?
That only tests whether there's a packet waiting. If you're polling for user input and waiting for packets from libpcap, you want to test whether there's a packet waiting *or* if there's user input waiting, so you'd do a "select()" or "poll()" on the file descriptors for one *OR MORE* "pcap_t"s (as Yoann noted, you might be waiting for packets on more than one device) *and* on the file descriptor for user input. As such, "pcap_is_packet_waiting()" would have to take a set of file descriptors as arguments, not just a single "pcap_t" and a timeout - but, at that point, it looks just like "select()" or "poll()", in which case, well, why not just use "select()" or "poll()"? Note also that, at least for GUI toolkits for X, the toolkit has its own main input loop, and has a mechanism by which you can add additional file descriptors to the "select()" or "poll()" in that loop, so you wouldn't do the test yourself at all - you'd just add the file descriptors for the various "pcap_t"s from which you're reading to the input set for your GUI toolkit, with callbacks that would call "pcap_dispatch()". - 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
