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
