On Feb 2, 2004, at 5:02 AM, Loris Degioanni wrote:
pcap_next_ex() is NOT blocking: it receives a single packet and returns it
to the calling program. It can block for a long period if you specify a big
timeout value in pcap_open_live(), but this is a problem that libpcap cannot
solve: simply, open the adapter with a shorter timeout.
That depends on your definition of "blocking"; my definition is that something is "blocking" if it'll wait for some event to occur, rather than immediately returning an "event hasn't occurred" indication, even if the wait isn't a wait that lasts forever.
Similarly, pcap_next_ex() has nothing to do with pcap_breakloop(), since
pcap_next_ex() never loops.
No, but it calls the read operation for the pcap_t on which a capture is being done, and *that* might loop.
Unix's libpcap doc has pcap_breakloop(). But doc says it will not unblock
pcap_loop() if issued in another thread. Doc says you need to use
pthread_cancel.
I don't see any mentions to pthread_cancel in the libpcap manual at www.tcpdump.org.
It doesn't mention it by name, but what the current version of the man page says is
Note also that, in a multi-threaded application, if one thread is
blocked in pcap_dispatch(), pcap_loop(), pcap_next(), or
pcap_next_ex(), a call to pcap_breakloop() in a different thread will
not unblock that thread; you will need to use whatever mechanism the OS
provides for breaking a thread out of blocking calls in order to
unblock the thread, such as thread cancellation in systems that support
POSIX threads.and "thread cancellation in systems that support POSIX threads" is done with "pthread_cancel()".
On the other side, the manual says, about pcap_breakloop(),
This routine is safe to use inside a signal handler on UNIX or a console
control handler on Windows
Since I don't see any problems in setting a flag in a structure (this is
what pcap_breakloop() does) from a different thread, I'm inclined to
interpret this statement as "pcap_breakloop() can be invoked from another
execution entity, like for example a different thread", and in fact console
control handlers in Windows, if I remember well, are implmented as separate
threads.
The statement is intended to be interpreted as "it doesn't modify a data structure in ways that will cause problems if another thread is also reading or writing the data structure". It doesn't guarantee that a blocking kernel trap will be interrupted, however, which is why the documentation says it won't unblock the thread. On UNIX systems, if it's called from a signal handler, the signal itself should unblock the kernel trap (causing it to return -1 an dset "errno" to EINTR), at least in a single-threaded program. That won't necessarily be the case on Windows.
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
