On Tue, May 08, 2007 at 06:10:29PM -0700, Christopher Layne wrote: > On Tue, May 08, 2007 at 02:03:17PM -0700, Niels Provos wrote: > > On 5/8/07, Phil Oleson <[EMAIL PROTECTED]> wrote: > > >So.. To fix your implementation you will need to do something like I did. > > >I reimplemented libevents' gettime() function (because it's not exposed > > >via event.h) and use it instead of calling time(NULL); > > > > I don't really understand why you are saying that. Timeouts are > > incremental and not in absolute time. So, you don't really need to > > understand anything about the underlying implementation. > > To me, it seems like the timeouts do not reset on an EV_PERSIST event that > 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. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
