Re: [Libevent-users] Libevent 1.4.9-stable slower than 1.3c?
On Tue, Apr 14, 2009 at 11:23:24PM -0700, Haiping Zhao wrote: [...] > Anyways, I'll have to re-think our model. At the same time, may I > ask why the change? Was that for calling gettimeofday() less number > of times to be more efficient? But the code only updates > base->tv_cache once per loop, each of which may take several > milliseconds to finish. Doesn't that leave huge space for an > inaccurate timestamp? Adrian is right that the call can be expensive on some platforms. But you're right that sometimes timing accuracy matters more than performance. This would seem to be a great candidate for an event base configuration flag in the 2.0.x series: there could be a new flag in the event_base_config_flags enumeration to disable the timeval cache. Anybody want to code it up? yrs, -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] epoll_wait problems
On Mon, Mar 23, 2009 at 02:23:37PM +0100, Richter, J??rg wrote: > Hi, > > Not really libevent specific, but perhaps someone here has seen this before > and can help me with this one. > > The problem is that epoll_wait hangs longer than requested. > This is a "strace -t -T -e epoll_wait" output of one such call: > > 12:07:08 epoll_wait(4, {{EPOLLIN, {u32=144477200, u64=144477200}}}, 1023, > 2347024) = 1 <4575.649567> > > Here you see that the call takes 4575 seconds, but epoll_wait was only > requested to wait 2347 seconds. > epoll_wait would have waited longer, but fd activity made it return. Without > fd activity it would have waited much longer. > This is reproducible. > > Is there a maximum timeout epoll_wait can handle? > Perhaps you have any other ideas what this might be? Sorry for the delay. There is indeed a wart in (most? all) versions of the Linux epoll implementation where the timeout maxes out at (LONG_MAX - 999UL) / HZ milliseconds. If your long is 32 bits, and your HZ is 1000, this tops out at a little over 2147 msec for you. Libevent versions later than 1.4.4-stable work around this. -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] epoll keyed wakeups - Patch merged on 2.6.30-rc1
On Wed, Apr 08, 2009 at 08:33:58AM -0700, Raine Fan wrote: > Hi! I'm just curious if libevent 1.5/2.0 will be carrying this > improvements (epoll keyed wakeups - see article on LWN.net: > http://lwn.net/Articles/317489/) from epoll patch set that was > merged recently on kernel 2.6.30-rc1 this week. Reading over the test code, I can't figure out if there is actually a new API here. If I understand correctly, we may be getting the benefits of this for free on any system with the new kernel code. Am I missing something that we'd need to do for this? -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] epoll keyed wakeups - Patch merged on 2.6.30-rc1
On Thu, Apr 23, 2009 at 9:38 AM, Nick Mathewson wrote: > Reading over the test code, I can't figure out if there is actually a > new API here. If I understand correctly, we may be getting the > benefits of this for free on any system with the new kernel code. Am > I missing something that we'd need to do for this? My impression was that these were kernel level changes that did not affect the API. Niels. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 1.4.9-stable slower than 1.3c?
I was thinking about an easier change, which is to add another timer update before timeout_correct(base, &tv). This is the function that could be using an out-of-date timestamp, if event_process_active(base) takes longer than expected. But sorry I really couldn't find any bandwidth to verify whether the change will work or not. -Haiping On 4/23/09 9:06 AM, "Nick Mathewson" wrote: On Tue, Apr 14, 2009 at 11:23:24PM -0700, Haiping Zhao wrote: [...] > Anyways, I'll have to re-think our model. At the same time, may I > ask why the change? Was that for calling gettimeofday() less number > of times to be more efficient? But the code only updates > base->tv_cache once per loop, each of which may take several > milliseconds to finish. Doesn't that leave huge space for an > inaccurate timestamp? Adrian is right that the call can be expensive on some platforms. But you're right that sometimes timing accuracy matters more than performance. This would seem to be a great candidate for an event base configuration flag in the 2.0.x series: there could be a new flag in the event_base_config_flags enumeration to disable the timeval cache. Anybody want to code it up? yrs, -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] Evhttp's HTTP protocol version handling
Hey, I just found evhttp's pretty picky about HTTP request without correct protocol version. For example, "GET /status.php\r\n", instead of "GET /status.php HTTP/1.1\r\n". So I'm suggesting this change, --- http.c 2008-12-19 14:27:27.0 -0800 +++ /var/users/hzhao/hphp/external/libevent/libevent-1.4.9-stable/http.c 2009-04-18 23:06:53.413896000 -0700 @@ -1259,11 +1259,13 @@ if (line == NULL) return (-1); uri = strsep(&line, " "); - if (line == NULL) - return (-1); + if (line == NULL) { + version = "HTTP/1.0"; +} else { version = strsep(&line, " "); if (line != NULL) return (-1); +} This is how Apache handles it, and this was why some of our hardware sending bad HTTP requests to Apache server without any problems, then when I switched to evhttp, it wasn't forgiving enough. /* Avoid sscanf in the common case */ if (len == 8 && pro[0] == 'H' && pro[1] == 'T' && pro[2] == 'T' && pro[3] == 'P' && pro[4] == '/' && apr_isdigit(pro[5]) && pro[6] == '.' && apr_isdigit(pro[7])) { r->proto_num = HTTP_VERSION(pro[5] - '0', pro[7] - '0'); } else if (3 == sscanf(r->protocol, "%4s/%u.%u", http, &major, &minor) && (strcasecmp("http", http) == 0) && (minor < HTTP_VERSION(1, 0)) ) /* don't allow HTTP/0.1000 */ r->proto_num = HTTP_VERSION(major, minor); else r->proto_num = HTTP_VERSION(1, 0); Thanks for looking into this! -Haiping ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] Libevent tutorial and reference manual
Hi, all. I've started work on a tutorial and reference manual for Libevent. Right now, they're far from complete: the tutorial only has a few examples, and the reference manual has nothing but instructions on how to create and use an event_base. You can get the latest version from http://wangafu.net/~nickm/libevent-book/TOC.html The documents are written in AsciiDoc and stored in a Git repository. You can get the latest version of the source with git clone git://git.torproject.org/~nickm/git/lebook Please let me know if you have any comments, corrections, suggestions, or help. My favorite form for any corrections would be as a patch to the AsciiDoc source. Anything else, I'd need to translate back. yrs, -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users