On Tue, May 08, 2007 at 06:38:51PM -0700, William Ahern wrote: > > received a non-timeout event. In a way this is absolute, not in the epoch > > sense, but that it's tied to the time event_add() was called and not > > relative > > to when the last valid event was received. > > That may or may not make sense the majority of the time. > > Most of the time you're reading logical data atoms, not bytes. > > Say you set a timeout for 10 seconds, but a socket polled as ready once > every 9 seconds. Maybe there's a single byte available, maybe there's none > (because the event notification was spurious). You're line buffering, and > maybe you've set an upper bound on line length of 1000 bytes (e.g. SMTP). > > You could be polling for almost 3 hours if the peer trickled data > byte-by-byte. If the peer was exceptionally smart, he could keep the > connection open forever, by sending malformed packets which set the socket > state as ready but were subsequently discarded further down the TCP stack.
Sure, but this is already way higher level than libevent would be concerned with. Additionally it's easily (relatively) handled by keeping track of the exceptional states and reacting against it. Besides, libevent has no notion of completion or even a way to provide that by a particular metric or count. It's concerned with readiness about the most basic level. If an event is fired, the timeout should be implicitly reset to 0, awaiting either the next valid event to reset the timeout again or a timeout itself for which to make the timeout event valid in the first place. -cl _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
