Re: [Libevent-users] does libevent2 or "libevent2 on unbutun" trigger EV_READ events unexpectedly ?

[William Ahern <william@xxxxxxxxxxxxxxxxxx>]

On Mon, Oct 19, 2015 at 06:01:48AM +0200, liu wen wrote:
> I have two laptops, one with fedora system, libevent
> and one with unbuntu system, libevent2
> 
> and I have two programs, one has a event related to read() while the other
> has an event related to pcap(libpcap: normally, when libpcap captures
>  packet, the event should be triggered)
> 
> I notice there are always false events, the read() returns -1 and the error
> is "Resource temporarily unavailable". the pcap captures 0 packets when the
> related event is triggered. this is really strange.
> 
> when the libpcap program runs on fedora laptop, it works fine
> 
> so I'm wondering does libevent2 or "libevent2 on unbutun" trigger EV_READ
> events unexpectedly ?

I don't know if this _particular_ pattern of behavior is symptomatic of a
bug somewhere, but in general spurious event notification is to be expected,
especially under high load or on networks with bad equipment. In my own
experience I most often encounter it because of Linux's delayed
checksumming:

	1) packet arrives in queue
	2) socket is notified
	3) application calls read(2)
	4) kernel verifies the checksum
	5) checksum fails
	6) packet discarded
	7) read returns EAGAIN

I've also experienced spurious write notification, although I don't remember
the precise mechanism. In both scenarios this was related to UDP and DNS.
Probably because without flow control it's much easier to unintentionally
flood the network under high load.

The delayed checksumming issue is less commonly encountered today because
many NICs will verify checksums on the card. Another common but more
intuitive scenario is a multi-threaded application, where two threads are
signaled, and the second one to respond sees EAGAIN.

As a general matter, just because an event is signaled doesn't mean you'll
be able to complete the operation, especially when it comes to socket I/O.
Always beware of TOCTTOU bugs.

Note that this isn't specific to libevent, but to Unix-syle event signaling
in general. It's not just Linux where this can happen, it's just more common
because of Linux's delayed checksumming, overly aggressive output buffering,
and other optimizations.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.