Re: [Libevent-users] EV_PERSIST behavior
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. Niels. Blah.. okay, my bad. I saw the call to time(NULL) and made a assumption that I didn't verify. There was no timersub() or such use from that call. I was juggling way too many things at the time and I should have refrained from responding until I had time to process the question better. -Phil. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] EV_PERSIST behavior
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
Re: [Libevent-users] EV_PERSIST behavior
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
Re: [Libevent-users] EV_PERSIST behavior
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. -cl ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] EV_PERSIST behavior
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. Niels. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] EV_PERSIST behavior
Christopher Layne wrote: I understand that EV_PERSIST basically means that one does not have to continually reschedule the event upon the event occuring. Consider the following simple test case and my following question on it... Documentation for that is here: The function event_add() schedules the execution of the ev event when the event specified in event_set() occurs or in at least the time speci- fied in the tv. If tv is NULL, no timeout occurs and the function will only be called if a matching event occurs on the file descriptor. The event in the ev argument must be already initialized by event_set() and may not be used in calls to event_set() until it has timed out or implies event_del() --> ^ been removed with event_del(). If the event in the ev argument already has a scheduled timeout, the old timeout will be replaced by the new one. Just took a bit to find it in the manpage. It might want to be more explictly stated in the documentation. Well, I've dealt with this before, so I'll give you the rundown. libevent uses clock_gettime() and CLOCK_MONOTONIC within it's queues to keep events happening across time changes on the system. 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); -Phil. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
