[Guy Harris <guy@xxxxxxxxxxxx>]

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.