frederic heem wrote: > Do you mean that on Solaris, when a read blocks and no packet arrives, the > read hangs forever ?
Yes. The purpose of the timer on Solaris is *NOT* to ensure that reads always complete within a fixed period of time. The purpose of the timer is to ensure that if packets are arriving slowly, a packet won't remain queued up and unread indefinitely. The pcap man page explicitly avoids making any claim that the timer will ensure that a read will complete within the timeout period. >> I.e., any code that depends on the timer preventing a read on a pcap_t >> from taking more than the specified amount of time is depending on >> something that libpcap does not and will not guarantee (and the libpcap >> man page explicitly indicates this). Does your code depend on that? > Indeed, it depends on the fact that pcap_breakloop shall return in a time > which ha to be predictable. See other bug report about this subject: > https://sourceforge.net/tracker/index.php?func=detail&aid=1575387&group_id=53067&atid=469577 The problem there is that there's no way for a pcap_breakloop() call in one thread to "poke" the descriptor/handle associated with a pcap_t to force it to return (other than to close it, but pcap_breakloop() is intended to leave the pcap_t usable; a reopen of the device, followed by a replacement of the descriptor in the pcap_t with the new descriptor, followed by a close of the original device, might achieve that, although that'd have to be done carefully to ensure it's thread-safe). If you call pcap_breakloop() within a signal handler, and the signal is delivered to the thread reading from the descriptor, and the signal is set to interrupt system calls, pcap_breakloop() will work. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
