From liusifan at gmail.com Sun Jul 1 08:18:27 2007 From: liusifan at gmail.com (liusifan) Date: Sun Jul 1 08:18:43 2007 Subject: [Libevent-users] A server framework library based on libeventthat implements the Half-Sync/ References: <200703150934309214983@21cn.com>, <20070315023017.GA24660@wilbur.25thandClement.com>, <200703151649481407698@21cn.com>, <7e63f56c0703150312n1f4f5e79u9be577600116706c@mail.gmail.com>, <200703151836079062238@21cn.com>, <45F92439.7090004@kaspersky.com>, <7e63f56c0703150404v94260d4g5a46ca1f3801be2f@mail.gmail.com>, <200703191028455312420@21cn.com>, Message-ID: <200707012018249063926@gmail.com> SGksIFNjb3R0IExhbWINCg0KVGhpcyBhcnRpY2xlIGRlc2NyaWJlcyB0aGUgd2F5IGxpa2UgeW91 IG1lbnRpb25lZC4NCg0KNS4gQXN5bmNocm9ub3VzIHJlc3VsdHMgYW5kIGNvbGxlY3Rpb25zIG9m IHJlc3VsdHMNCmh0dHA6Ly90ZXJhYml0LmNvbS5hdS9kb2NzL1Byb2FjdG9yMi5odG0jX1RvYzc2 Mzk4OTY2DQoNCkkgZm9sbG93IHRoaXMgYXJ0aWNsZSB0byBkZXZlbG9wZSBhbiBMZWFkZXIvRm9s bG93ZXIgdGhyZWFkIHBvb2wgDQpzZXJ2ZXIgYmFzZWQgb24gbGliZXZlbnQuIEZvbGxvd2luZyBp cyB0aGUgc291cmNlIGNvZGU6DQpodHRwOi8vc3BzZXJ2ZXIuZ29vZ2xlY29kZS5jb20vZmlsZXMv c3BzZXJ2ZXItMC42LnNyYy50YXIuZ3oNCg0KDQpCZXN0IHJlZ2FyZHOjrA0KDQpsaXVzaWZhbg0K MjAwNy0wNy0wMQ0KDQo+Pj4NCj5PbiBNYXIgMTgsIDIwMDcsIGF0IDc6MjggUE0sIGxpdXNpZmFu IHdyb3RlOg0KPg0KPj4gSSBoYXZlIG5vdCBmb3VuZCBzb21ldGhpbmcgbGlrZSBBQ0VfVFBfUmVh Y3Rvcjo6ZGlzcGF0Y2hfaSBpbiAgDQo+PiBsaWJldmVudC4NCj4+IFNvIGkgdGhpbmsgaXQgY291 bGQgbm90IGltcGxlbWVudCBMRiBwYXR0ZXJuIHdpdGggY3VycmVudCB2ZXJzaW9uICANCj4+IG9m IGxpYmV2ZW50Lg0KPj4NCj4+IERpZCBpIG1pc3Mgc29tZXRoaW5nPyBUaGFua3MgaW4gYWR2YW5j ZS4NCj4NCj5JIHRoaW5rIHlvdSBjb3VsZCBhbHdheXMgZG8gaXQgYnkgZG9pbmcgeW91ciBvd24g cXVldWVpbmcgYWZ0ZXIgIA0KPmxpYmV2ZW50J3MuIEknbSBub3Qgc3VyZSBob3cgbGFyZ2UgdGhl IHBlcmZvcm1hbmNlIGltcGFjdCB3b3VsZCBiZS4NCj4NCj5UaGF0IHdhcyBhbiBpbnRlcmVzdGlu ZyBwYXBlciwgYnkgdGhlIHdheS4gSSd2ZSBiZWVuIHRoaW5raW5nIG9mICANCj5pbXBsZW1lbnRp bmcgc29tZXRoaW5nIGxpa2UgaXQsIGFuZCBpdCdzIG5pY2UgdG8ga25vdyB0aGUgbmFtZSAgDQo+ c29tZW9uZSdzIGdpdmVuIHRvIGl0Lg0KPg0KPi0tIA0KPlNjb3R0IExhbWIgPGh0dHA6Ly93d3cu c2xhbWIub3JnLz4NCj4NCj4NCj4NCgkJCQ0KDQo= From david.w.h.chin at gmail.com Tue Jul 3 00:30:01 2007 From: david.w.h.chin at gmail.com (David Chin) Date: Tue Jul 3 00:30:06 2007 Subject: [Libevent-users] event.h Revision: 368 Message-ID: I had to include stdint.h in event.h for libevent to compile on OS X 10.3.9 -- Email: david.w.h.chin AT gmail.com dwchin AT lroc.harvard.edu Public key: http://gallatin.physics.lsa.umich.edu/~dwchin/crypto.html pub 1024D/1C557DDF 2006-07-21 [expires: 2007-07-21] Key fingerprint = 4EEB A409 5010 3679 4EA7 D420 4E52 202A 1C55 7DDF From liusifan at gmail.com Thu Jul 5 07:57:21 2007 From: liusifan at gmail.com (lau stephen) Date: Thu Jul 5 07:57:24 2007 Subject: [Libevent-users] A server framework library based on libeventthat implements the Half-Sync/ In-Reply-To: <200707012018249063926@gmail.com> References: <200703150934309214983@21cn.com> <20070315023017.GA24660@wilbur.25thandClement.com> <200703151649481407698@21cn.com> <7e63f56c0703150312n1f4f5e79u9be577600116706c@mail.gmail.com> <200703151836079062238@21cn.com> <45F92439.7090004@kaspersky.com> <7e63f56c0703150404v94260d4g5a46ca1f3801be2f@mail.gmail.com> <200703191028455312420@21cn.com> <200707012018249063926@gmail.com> Message-ID: Hi, Scott Lamb This article describes the way like you mentioned. 5. Asynchronous results and collections of results http://terabit.com.au/docs/Proactor2.htm#_Toc76398966 I follow this article to develope an Leader/Follower thread pool server based on libevent. Following is the source code: http://spserver.googlecode.com/files/spserver-0.6.src.tar.gz Best regards£¬ liusifan >>> > >On Mar 18, 2007, at 7:28 PM, liusifan wrote: > > > >> I have not found something like ACE_TP_Reactor::dispatch_i in > >> libevent. > >> So i think it could not implement LF pattern with current version > >> of libevent. > >> > >> Did i miss something? Thanks in advance. > > > >I think you could always do it by doing your own queueing after > >libevent's. I'm not sure how large the performance impact would be. > > > >That was an interesting paper, by the way. I've been thinking of > >implementing something like it, and it's nice to know the name > >someone's given to it. > > > >-- > >Scott Lamb > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070705/2c038f96/attachment.htm From rakesh_usenet at yahoo.com Wed Jul 11 14:16:59 2007 From: rakesh_usenet at yahoo.com (Rakesh K Sinha) Date: Wed Jul 11 14:24:24 2007 Subject: [Libevent-users] Newbie Question - event_test.c hangs Message-ID: <922052.10404.qm@web63904.mail.re1.yahoo.com> Hi - I am a newbie to libevent , interested in the same because I am writing an high-performance server that is supposed to take a lot of transaction hits per second. I got the event test.c in the home page to get started. http://monkey.org/~provos/libevent/event-test.c I downloaded the latest version of libevent - 1.3a . Built the same. When I try to run the application - I am seeing the following . $ ./event-test Write data to event.fifo What is the sample application supposed to do ? Why would it hang on the event_dispatch() call at the end of main() . Am I missing something important here. Thanks for your help. My kernel version is 2.6+ . So I guess epoll is supported on my Linux box - Redhat EL. $ rpm -qa | grep kernel kernel-ib-1.0-1 kernel-utils-2.4-13.1.83 kernel-2.6.9-42.0.0.0.1.EL ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070711/ad1f3916/attachment.htm From rakesh_usenet at yahoo.com Thu Jul 12 20:40:37 2007 From: rakesh_usenet at yahoo.com (Rakesh K Sinha) Date: Thu Jul 12 20:40:46 2007 Subject: [Libevent-users] Newbie Question - event_test.c hangs Message-ID: <738791.11406.qm@web63906.mail.re1.yahoo.com> Thanks Thomas. That works for me. ----- Original Message ---- From: Thomas Lindgren To: Rakesh K Sinha Sent: Wednesday, July 11, 2007 2:15:47 PM Subject: Re: [Libevent-users] Newbie Question - event_test.c hangs On 7/11/07, Rakesh K Sinha wrote: Hi - I am a newbie to libevent , interested in the same because I am writing an high-performance server that is supposed to take a lot of transaction hits per second. I got the event test.c in the home page to get started. http://monkey.org/~provos/libevent/event-test.c I downloaded the latest version of libevent - 1.3a . Built the same. When I try to run the application - I am seeing the following . $ ./event-test Write data to event.fifo What is the sample application supposed to do ? Why would it hang on the event_dispatch() call at the end of main() . Am I missing something important here. Thanks for your help. Here's what I did: $ cat > event.fifo foo bar $ and (in another window): $ ./event-test Write data to event.fifo fifo_read called with fd: 3, event: 2, arg: 0xbfb5f088 Read: foo fifo_read called with fd: 3, event: 2, arg: 0xbfb5f088 Read: bar Hope this helps. Best, Thomas ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070712/39612e3a/attachment-0001.htm From adrian at creative.net.au Fri Jul 13 02:56:21 2007 From: adrian at creative.net.au (Adrian Chadd) Date: Fri Jul 13 02:53:19 2007 Subject: [Libevent-users] evhttp questions Message-ID: <20070713065620.GD7456@skywalker.creative.net.au> G'day, I'm looking at the evhttp code to build a simple HTTP proxy for some testing. Unfortunately about the only example I can find of the evhttp code is Niels' spybye and as far as I can tell there's no "streaming" between client and server - request and reply bodies are fully read into an evbuffer and then written out in one hit. Ideally what I'd like to be able to do is receive callbacks from evhttp when the buffers are full/empty so I can schedule further operations. Unfortunately there doesn't seem to be any easy way of doing it within the current code. Have I missed something, or will I have to patch evhttp to provide the extra functionality? Eg, I can begin writing out via evhttp_send_reply_start() and evhttp_send_reply_chunk() but I can't find anything in the current API that can be hooked into to be informed when the chunk has been written so I can - if possible - schedule another chunk. Also, I can't seem to find any support for trailers in the codebase. Have I just missed it? Thanks, Adrian From slamb at slamb.org Thu Jul 19 16:14:58 2007 From: slamb at slamb.org (Scott Lamb) Date: Thu Jul 19 16:15:29 2007 Subject: [Libevent-users] [PATCH] initialize ev_res Message-ID: <469FC642.3040604@slamb.org> When I use "valgrind --tool=memcheck" on a libevent-based program, it gives the following complaint: ==15442== Conditional jump or move depends on uninitialised value(s) ==15442== at 0x4C0F2D3: event_add (event.c:632) ==15442== by 0x405EE4: main_loop (net.c:356) ==15442== by 0x411853: main (tincd.c:329) Here's the relevant portion of event.c: 632 if ((ev->ev_flags & EVLIST_ACTIVE) && 633 (ev->ev_res & EV_TIMEOUT)) { I've looked through the libevent code and verified that ev_res is always initialized when (ev_flags & EVLIST_ACTIVE) is true, so there's no real bug here. However, it's useful to suppress noise in valgrind output, and there's no real cost to initializing ev_res at event_set time. Thus the attached patch. Best regards, Scott -- Scott Lamb -------------- next part -------------- Avoid valgrind warning ==15442== Conditional jump or move depends on uninitialised value(s) ==15442== at 0x4C0F2D3: event_add (event.c:632) ==15442== by 0x405EE4: main_loop (net.c:356) ==15442== by 0x411853: main (tincd.c:329) Index: event.c =================================================================== --- event.c (revision 369) +++ event.c (working copy) @@ -530,6 +530,7 @@ ev->ev_arg = arg; ev->ev_fd = fd; ev->ev_events = events; + ev->ev_res = 0; ev->ev_flags = EVLIST_INIT; ev->ev_ncalls = 0; ev->ev_pncalls = NULL; From elliotf-libevent at gratuitous.net Fri Jul 20 13:43:43 2007 From: elliotf-libevent at gratuitous.net (Elliot F) Date: Fri Jul 20 13:43:47 2007 Subject: [Libevent-users] conflict checked into subversion (tags/release-1.3b/libevent/configure.in) Message-ID: <46A0F44F.5020702@gratuitous.net> It appears that a subversion conflict got checked into subversion. Line 4 of configure.in has the conflict listed, which b0rks the configure script when run. Just an FYI. Thanks, Elliot From sq at sqstudio.ru Mon Jul 23 06:41:37 2007 From: sq at sqstudio.ru (Dmitry Lohansky) Date: Mon Jul 23 06:41:53 2007 Subject: [Libevent-users] offtop In-Reply-To: <46A0F44F.5020702@gratuitous.net> References: <46A0F44F.5020702@gratuitous.net> Message-ID: <984601627.20070723144137@sqstudio.ru> > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users Not http://monkey.org, but http://monkeymail.org -- W/ best regards, Dmitry From slamb at slamb.org Wed Jul 25 02:48:19 2007 From: slamb at slamb.org (Scott Lamb) Date: Wed Jul 25 02:48:56 2007 Subject: [Libevent-users] rtsig doesn't compile - remove? Message-ID: <46A6F233.9040408@slamb.org> While composing a patch (more on that later), I noticed that rtsig.c doesn't even compile. In particular, * it uses signalqueue, which was removed in revision 351 * it has an unnamed function argument, which isn't legal C! (only C++) * it uses , which of course is Linux-only * it uses _syscall0, which hasn't existed for quite some time Niels, how would you feel about removing rtsig entirely? It's the most complex mechanism (985 lines...others range from epoll @ 364 lines to kqueue at 413 lines) and totally obsolete/unmaintained. Modern Linux people are all using epoll_wait(), and older ones must be content with select()/poll() or they would have complained about rtsig's status. Best regards, Scott -- Scott Lamb From slamb at slamb.org Wed Jul 25 15:53:39 2007 From: slamb at slamb.org (Scott Lamb) Date: Wed Jul 25 15:54:38 2007 Subject: [Libevent-users] [PATCHES] use monotonic clock & infinite timeouts Message-ID: <46A7AA43.7010009@slamb.org> libevent's monotonic clock detection is currently broken on all platforms. The first attached patch fixes it. The second takes advantage of it to remove the 5-second idle timeout where possible. This is starting to become a big deal on Linux, where they've removed ticks from the kernel and are now using tools (PowerTOP) to remove unnecessary wakeups from userspace. This effort is greatly extending my battery life. I've successfully run test/test.sh with these patches on OS X 10.4 (which does not have clock_gettime()) and Linux 2.6 (which does). So it's been tested with all event methods except devpoll (sorry, no Solaris machine handy at the moment) and rtsig (which won't compile with or without these patches). On Linux, I've verified with strace and PowerTOP that it's actually using CLOCK_MONOTONIC and infinite timeouts. Best regards, Scott -- Scott Lamb -------------- next part -------------- >From bbf1036054ba1546682c6c130d4b77e2ee95b264 Mon Sep 17 00:00:00 2001 From: Scott Lamb Date: Wed, 25 Jul 2007 12:06:17 -0700 Subject: [PATCH] use CLOCK_MONOTONIC where available * look for clock_gettime in librt, which is used on Linux * remove check for HAVE_CLOCK_MONOTONIC (there was no configure glue) * detect at runtime - useful if a libevent-based program is run on an older kernel than it is compiled on Signed-off-by: Scott Lamb --- libevent/configure.in | 1 + libevent/event.c | 37 +++++++++++++++++++++++++------------ 2 files changed, 26 insertions(+), 12 deletions(-) mode change 100644 => 100755 libevent/autogen.sh diff --git a/libevent/autogen.sh b/libevent/autogen.sh old mode 100644 new mode 100755 diff --git a/libevent/configure.in b/libevent/configure.in index 507090b..1acfa84 100644 --- a/libevent/configure.in +++ b/libevent/configure.in @@ -37,6 +37,7 @@ AC_ARG_WITH(rtsig, dnl Checks for libraries. AC_CHECK_LIB(socket, socket) AC_CHECK_LIB(resolv, inet_aton) +AC_CHECK_LIB(rt, clock_gettime) dnl Checks for header files. AC_HEADER_STDC diff --git a/libevent/event.c b/libevent/event.c index 2048157..fc54d23 100644 --- a/libevent/event.c +++ b/libevent/event.c @@ -51,6 +51,7 @@ #include #include #include +#include #include "event.h" #include "event-internal.h" @@ -113,6 +114,7 @@ const struct eventop *eventops[] = { /* Global state */ struct event_base *current_base = NULL; extern struct event_base *evsignal_base; +static int use_monotonic; /* Handle signals - This is a deprecated interface */ int (*event_sigcb)(void); /* Signal callback when gotsig is set */ @@ -143,25 +145,34 @@ compare(struct event *a, struct event *b) return (0); } +static void +detect_monotonic(void) +{ +#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) + struct timespec ts; + + if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) + use_monotonic = 1; +#endif +} + static int gettime(struct timeval *tp) { -#ifdef HAVE_CLOCK_GETTIME +#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) struct timespec ts; -#ifdef HAVE_CLOCK_MONOTONIC - if (clock_gettime(CLOCK_MONOTONIC, &ts) == -1) -#else - if (clock_gettime(CLOCK_REALTIME, &ts) == -1) -#endif - return (-1); - tp->tv_sec = ts.tv_sec; - tp->tv_usec = ts.tv_nsec / 1000; -#else - gettimeofday(tp, NULL); + if (use_monotonic) { + if (clock_gettime(CLOCK_MONOTONIC, &ts) == -1) + return (-1); + + tp->tv_sec = ts.tv_sec; + tp->tv_usec = ts.tv_nsec / 1000; + return (0); + } #endif - return (0); + return (gettimeofday(tp, NULL)); } RB_PROTOTYPE(event_tree, event, ev_timeout_node, compare); @@ -180,6 +191,8 @@ event_init(void) event_sigcb = NULL; event_gotsig = 0; + + detect_monotonic(); gettime(&base->event_tv); RB_INIT(&base->timetree); -- 1.5.3.GIT -------------- next part -------------- >From d7f9e3b60c9bf5b1a9daf9cc9ec027d16c944816 Mon Sep 17 00:00:00 2001 From: Scott Lamb Date: Wed, 25 Jul 2007 11:40:16 -0700 Subject: [PATCH] remove unnecessary wakeups on idle libevent wakes up every 5 seconds to check if the clock has gone backwards. On platforms with CLOCK_MONOTONIC, this is unnecessary. With the new Linux effort to reduce wakeups for laptops (e.g., PowerTOP) and libevent starting to show up in standard system tools (e.g., rpc.idmapd), it's better to avoid this where possible. Signed-off-by: Scott Lamb --- libevent/devpoll.c | 5 +++-- libevent/epoll.c | 6 ++++-- libevent/event.c | 51 +++++++++++++++++++++++++++++++-------------------- libevent/kqueue.c | 9 ++++++--- libevent/poll.c | 9 ++++++--- libevent/rtsig.c | 36 ++++++++++++++++++++++++------------ 6 files changed, 74 insertions(+), 42 deletions(-) diff --git a/libevent/devpoll.c b/libevent/devpoll.c index 96582ab..d1327e5 100644 --- a/libevent/devpoll.c +++ b/libevent/devpoll.c @@ -218,12 +218,13 @@ devpoll_dispatch(struct event_base *base, void *arg, struct timeval *tv) struct pollfd *events = devpollop->events; struct dvpoll dvp; struct evdevpoll *evdp; - int i, res, timeout; + int i, res, timeout = -1; if (devpollop->nchanges) devpoll_commit(devpollop); - timeout = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; + if (tv != NULL) + timeout = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; dvp.dp_fds = devpollop->events; dvp.dp_nfds = devpollop->nevents; diff --git a/libevent/epoll.c b/libevent/epoll.c index 235977d..2be06d6 100644 --- a/libevent/epoll.c +++ b/libevent/epoll.c @@ -187,9 +187,11 @@ epoll_dispatch(struct event_base *base, void *arg, struct timeval *tv) struct epollop *epollop = arg; struct epoll_event *events = epollop->events; struct evepoll *evep; - int i, res, timeout; + int i, res, timeout = -1; + + if (tv != NULL) + timeout = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; - timeout = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; res = epoll_wait(epollop->epfd, events, epollop->nevents, timeout); if (res == -1) { diff --git a/libevent/event.c b/libevent/event.c index fc54d23..e35bf74 100644 --- a/libevent/event.c +++ b/libevent/event.c @@ -127,7 +127,8 @@ static int event_haveevents(struct event_base *); static void event_process_active(struct event_base *); -static int timeout_next(struct event_base *, struct timeval *); +static int timeout_next(struct event_base *, struct timeval *, + struct timeval **); static void timeout_process(struct event_base *); static void timeout_correct(struct event_base *, struct timeval *); @@ -387,6 +388,7 @@ event_base_loop(struct event_base *base, int flags) const struct eventop *evsel = base->evsel; void *evbase = base->evbase; struct timeval tv; + struct timeval *tv_p; int res, done; if(!TAILQ_EMPTY(&base->sig.signalqueue)) @@ -415,19 +417,11 @@ event_base_loop(struct event_base *base, int flags) } } - /* Check if time is running backwards */ - gettime(&tv); - if (timercmp(&tv, &base->event_tv, <)) { - struct timeval off; - event_debug(("%s: time is running backwards, corrected", - __func__)); - timersub(&base->event_tv, &tv, &off); - timeout_correct(base, &off); - } - base->event_tv = tv; + timeout_correct(base, &tv); + tv_p = &tv; if (!base->event_count_active && !(flags & EVLOOP_NONBLOCK)) - timeout_next(base, &tv); + timeout_next(base, &tv, &tv_p); else timerclear(&tv); @@ -437,7 +431,7 @@ event_base_loop(struct event_base *base, int flags) return (1); } - res = evsel->dispatch(base, evbase, &tv); + res = evsel->dispatch(base, evbase, tv_p); if (res == -1) @@ -738,16 +732,19 @@ event_active(struct event *ev, int res, short ncalls) event_queue_insert(ev->ev_base, ev, EVLIST_ACTIVE); } -int -timeout_next(struct event_base *base, struct timeval *tv) +static int +timeout_next(struct event_base *base, struct timeval *tv, + struct timeval **tv_p) { - struct timeval dflt = TIMEOUT_DEFAULT; - struct timeval now; struct event *ev; + struct timeval dflt = TIMEOUT_DEFAULT; if ((ev = RB_MIN(event_tree, &base->timetree)) == NULL) { - *tv = dflt; + if (use_monotonic) + *tv_p = NULL; + else + *tv = dflt; return (0); } @@ -769,16 +766,30 @@ timeout_next(struct event_base *base, struct timeval *tv) } static void -timeout_correct(struct event_base *base, struct timeval *off) +timeout_correct(struct event_base *base, struct timeval *tv) { struct event *ev; + struct timeval off; + + if (use_monotonic) + return; + + /* Check if time is running backwards */ + gettime(tv); + if (timercmp(tv, &base->event_tv, >=)) { + return; + } + + event_debug(("%s: time is running backwards, corrected", + __func__)); + timersub(&base->event_tv, tv, &off); /* * We can modify the key element of the node without destroying * the key, beause we apply it to all in the right order. */ RB_FOREACH(ev, event_tree, &base->timetree) - timersub(&ev->ev_timeout, off, &ev->ev_timeout); + timersub(&ev->ev_timeout, &off, &ev->ev_timeout); } void diff --git a/libevent/kqueue.c b/libevent/kqueue.c index af2e0f1..c547806 100644 --- a/libevent/kqueue.c +++ b/libevent/kqueue.c @@ -212,13 +212,16 @@ kq_dispatch(struct event_base *base, void *arg, struct timeval *tv) struct kevent *changes = kqop->changes; struct kevent *events = kqop->events; struct event *ev; - struct timespec ts; + struct timespec ts, *ts_p = NULL; int i, res; - TIMEVAL_TO_TIMESPEC(tv, &ts); + if (tv != NULL) { + TIMEVAL_TO_TIMESPEC(tv, &ts); + ts_p = &ts; + } res = kevent(kqop->kq, changes, kqop->nchanges, - events, kqop->nevents, &ts); + events, kqop->nevents, ts_p); kqop->nchanges = 0; if (res == -1) { if (errno != EINTR) { diff --git a/libevent/poll.c b/libevent/poll.c index 8488598..123d36a 100644 --- a/libevent/poll.c +++ b/libevent/poll.c @@ -148,13 +148,16 @@ poll_check_ok(struct pollop *pop) int poll_dispatch(struct event_base *base, void *arg, struct timeval *tv) { - int res, i, sec, nfds; + int res, i, msec = -1, nfds; struct pollop *pop = arg; poll_check_ok(pop); - sec = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; + + if (tv != NULL) + msec = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000; + nfds = pop->nfds; - res = poll(pop->event_set, nfds, sec); + res = poll(pop->event_set, nfds, msec); if (res == -1) { if (errno != EINTR) { diff --git a/libevent/rtsig.c b/libevent/rtsig.c index 3267af9..e0e55af 100644 --- a/libevent/rtsig.c +++ b/libevent/rtsig.c @@ -750,7 +750,7 @@ rtsig_recalc(struct event_base *base, void *arg, int max) */ static inline int -do_poll(struct rtsigop *op, struct timespec *ts) +do_poll(struct rtsigop *op, struct timespec *ts, struct timespec **ts_p) { int res = 0; int i = 0; @@ -758,7 +758,11 @@ do_poll(struct rtsigop *op, struct timespec *ts) if (op->cur > 1) { /* non-empty poll set (modulo the signalfd) */ if (op->nonsock) { - int timeout = ts->tv_nsec / 1000000 + ts->tv_sec * 1000; + int timeout = -1; + + if (*ts_p != NULL) + timeout = (*ts_p)->tv_nsec / 1000000 + + (*ts_p)->tv_sec * 1000; sigprocmask(SIG_UNBLOCK, &(op->sigs), NULL); @@ -768,6 +772,7 @@ do_poll(struct rtsigop *op, struct timespec *ts) ts->tv_sec = 0; ts->tv_nsec = 0; + *ts_p = ts; } else { res = poll(op->poll, op->cur, 0); } @@ -777,6 +782,7 @@ do_poll(struct rtsigop *op, struct timespec *ts) } else if (res) { ts->tv_sec = 0; ts->tv_nsec = 0; + *ts_p = ts; } i = 0; @@ -894,17 +900,18 @@ do_siginfo_dispatch(struct event_base *base, struct rtsigop *op, * return -1 on error */ static inline int -do_sigwait(struct event_base *base, struct rtsigop *op, struct timespec *ts, - sigset_t *sigs) +do_sigwait(struct event_base *base, struct rtsigop *op, + struct timespec *ts, struct timespec **ts_p, sigset_t *sigs) { for (;;) { siginfo_t info; int signum; - signum = sigtimedwait(sigs, &info, ts); + signum = sigtimedwait(sigs, &info, *ts_p); ts->tv_sec = 0; ts->tv_nsec = 0; + *ts_p = ts; if (signum == -1) { if (errno == EAGAIN || errno == EINTR) @@ -920,7 +927,7 @@ do_sigwait(struct event_base *base, struct rtsigop *op, struct timespec *ts, static inline int do_signals_from_socket(struct event_base *base, struct rtsigop *op, - struct timespec *ts) + struct timespec *ts, struct timespec **ts_p) { int fd = op->signal_recv_fd; siginfo_t info; @@ -937,6 +944,7 @@ do_signals_from_socket(struct event_base *base, struct rtsigop *op, } else { ts->tv_sec = 0; ts->tv_nsec = 0; + *ts_p = ts; if (1 == do_siginfo_dispatch(base, op, &info)) return (1); } @@ -948,17 +956,21 @@ int rtsig_dispatch(struct event_base *base, void *arg, struct timeval *tv) { struct rtsigop *op = (struct rtsigop *) arg; - struct timespec ts; + struct timespec ts, *ts_p = NULL; int res; sigset_t sigs; - ts.tv_sec = tv->tv_sec; - ts.tv_nsec = tv->tv_usec * 1000; + if (tv != NULL) { + ts.tv_sec = tv->tv_sec; + ts.tv_nsec = tv->tv_usec * 1000; + *ts_p = ts; + } poll_for_level: - res = do_poll(op, &ts); /* ts can be modified in do_XXX() */ + /* ts and ts_p can be modified in do_XXX() */ + res = do_poll(op, &ts, &ts_p); - res = do_signals_from_socket(base, op, &ts); + res = do_signals_from_socket(base, op, &ts, &ts_p); if (res == 1) goto poll_for_level; else if (res == -1) @@ -973,7 +985,7 @@ rtsig_dispatch(struct event_base *base, void *arg, struct timeval *tv) signotset(&sigs); sigorset(&sigs, &sigs, &op->sigs); - res = do_sigwait(base, op, &ts, &sigs); + res = do_sigwait(base, op, &ts, &ts_p, &sigs); if (res == 1) goto poll_for_level; -- 1.5.3.GIT From slamb at slamb.org Wed Jul 25 16:51:26 2007 From: slamb at slamb.org (Scott Lamb) Date: Wed Jul 25 16:52:13 2007 Subject: [Libevent-users] [PATCHES] use monotonic clock & infinite timeouts In-Reply-To: <46A7AA43.7010009@slamb.org> References: <46A7AA43.7010009@slamb.org> Message-ID: <46A7B7CE.4020106@slamb.org> Scott Lamb wrote: > libevent's monotonic clock detection is currently broken on all > platforms. The first attached patch fixes it. The second takes advantage > of it to remove the 5-second idle timeout where possible. This is > starting to become a big deal on Linux, where they've removed ticks from > the kernel and are now using tools (PowerTOP) to remove unnecessary > wakeups from userspace. This effort is greatly extending my battery life. In fact, I just saw RedHat has a bug open specifically about libevent's 5-second timer. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204990 From slamb at slamb.org Wed Jul 25 20:21:25 2007 From: slamb at slamb.org (Scott Lamb) Date: Wed Jul 25 21:20:53 2007 Subject: [Libevent-users] [PATCHES] use monotonic clock & infinite timeouts In-Reply-To: <46A7AA43.7010009@slamb.org> References: <46A7AA43.7010009@slamb.org> Message-ID: <46A7E905.1050600@slamb.org> Scott Lamb wrote: > libevent's monotonic clock detection is currently broken on all > platforms. The first attached patch fixes it. The second takes advantage > of it to remove the 5-second idle timeout where possible. Actually, I don't think I understand the purpose of this timeout at all. I had thought it was to make some effort to adjust the timeout values if the system clock gets set backwards (related to timeout_correct()). But for that to make any sense, it'd have to be a limit on the time to wait when there are longer timeouts. Instead, it's a time to wait when there's no timeout scheduled at all. I don't think it accomplishes anything. Maybe the default timeout should be removed entirely, not just if a monotonic clock is available? Best regards, Scott -- Scott Lamb From elliotf-libevent at gratuitous.net Thu Jul 26 14:57:42 2007 From: elliotf-libevent at gratuitous.net (Elliot F) Date: Thu Jul 26 14:58:04 2007 Subject: [Libevent-users] fix for memory leak in evhttp_handle_chunked_read Message-ID: <46A8EEA6.8080503@gratuitous.net> A fix for a small memory leak in http.c's evhttp_handle_chunked_read. Thanks, Elliot diff -Naur libevent-1.3b_orig/http.c libevent-1.3b_modified/http.c --- libevent-1.3b_orig/http.c 2007-03-03 20:05:04.000000000 -0800 +++ libevent-1.3b_modified/http.c 2007-07-26 11:46:33.000000000 -0700 @@ -640,8 +640,10 @@ if (p == NULL) break; /* the last chunk is on a new line? */ - if (strlen(p) == 0) + if (strlen(p) == 0) { + free(p); continue; + } req->ntoread = strtol(p, &endp, 16); error = *p == '\0' || (*endp != '\0' && *endp != ' '); free(p); -------------- next part -------------- A non-text attachment was scrubbed... Name: memleak_fix-evhttp_handle_chunked_read.patch Type: text/x-patch Size: 497 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070726/dbbfd276/memleak_fix-evhttp_handle_chunked_read.bin From provos at citi.umich.edu Mon Jul 30 18:41:50 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 18:42:25 2007 Subject: [Libevent-users] [PATCHES] use monotonic clock & infinite timeouts In-Reply-To: <46A7E905.1050600@slamb.org> References: <46A7AA43.7010009@slamb.org> <46A7E905.1050600@slamb.org> Message-ID: <850f7cbe0707301541u75d96a5y88c50c56fe0879a7@mail.gmail.com> Thanks for the patches. I removed the default timeout. Your patch had a bug where timeout_correct no longer set event_tv correctly. I fixed that. Unfortunatley, the regression test currently fails on Mac OS X when compiled with -O2. Still trying to figure that one out. Niels. On 7/25/07, Scott Lamb wrote: > Scott Lamb wrote: > > libevent's monotonic clock detection is currently broken on all > > platforms. The first attached patch fixes it. The second takes advantage > > of it to remove the 5-second idle timeout where possible. > > Actually, I don't think I understand the purpose of this timeout at all. > I had thought it was to make some effort to adjust the timeout values if > the system clock gets set backwards (related to timeout_correct()). But > for that to make any sense, it'd have to be a limit on the time to wait > when there are longer timeouts. Instead, it's a time to wait when > there's no timeout scheduled at all. > > I don't think it accomplishes anything. Maybe the default timeout should > be removed entirely, not just if a monotonic clock is available? > > Best regards, > Scott > > -- > Scott Lamb > > From provos at citi.umich.edu Mon Jul 30 18:44:42 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 18:44:46 2007 Subject: [Libevent-users] rtsig doesn't compile - remove? In-Reply-To: <46A6F233.9040408@slamb.org> References: <46A6F233.9040408@slamb.org> Message-ID: <850f7cbe0707301543g58c1e2b0s4b83787bb1cc69fa@mail.gmail.com> I am fine with removing rtsig. I personally never liked that way to do event notification. If someone feels strongly, they can revive it from svn and fix it. Niels. Ps: Just got back from two weeks of essentially being offline :-) On 7/24/07, Scott Lamb wrote: > While composing a patch (more on that later), I noticed that rtsig.c > doesn't even compile. In particular, > > * it uses signalqueue, which was removed in revision 351 > * it has an unnamed function argument, which isn't legal C! (only C++) > * it uses , which of course is Linux-only > * it uses _syscall0, which hasn't existed for quite some time > > Niels, how would you feel about removing rtsig entirely? It's the most > complex mechanism (985 lines...others range from epoll @ 364 lines to > kqueue at 413 lines) and totally obsolete/unmaintained. Modern Linux > people are all using epoll_wait(), and older ones must be content with > select()/poll() or they would have complained about rtsig's status. > > Best regards, > Scott > > -- > Scott Lamb > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From provos at citi.umich.edu Mon Jul 30 19:49:09 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 19:49:12 2007 Subject: [Libevent-users] [PATCH] initialize ev_res In-Reply-To: <469FC642.3040604@slamb.org> References: <469FC642.3040604@slamb.org> Message-ID: <850f7cbe0707301649w2faa61b1s91ac1c56bb0c26fb@mail.gmail.com> Hi Scott, thanks for noticing this. It's submitted. Niels. On 7/19/07, Scott Lamb wrote: > When I use "valgrind --tool=memcheck" on a libevent-based program, it > gives the following complaint: > > ==15442== Conditional jump or move depends on uninitialised value(s) > ==15442== at 0x4C0F2D3: event_add (event.c:632) > ==15442== by 0x405EE4: main_loop (net.c:356) > ==15442== by 0x411853: main (tincd.c:329) > > Here's the relevant portion of event.c: > > 632 if ((ev->ev_flags & EVLIST_ACTIVE) && > 633 (ev->ev_res & EV_TIMEOUT)) { > > I've looked through the libevent code and verified that ev_res is always > initialized when (ev_flags & EVLIST_ACTIVE) is true, so there's no real > bug here. > > However, it's useful to suppress noise in valgrind output, and there's > no real cost to initializing ev_res at event_set time. Thus the attached > patch. > > Best regards, > Scott > > -- > Scott Lamb > > Avoid valgrind warning > > ==15442== Conditional jump or move depends on uninitialised value(s) > ==15442== at 0x4C0F2D3: event_add (event.c:632) > ==15442== by 0x405EE4: main_loop (net.c:356) > ==15442== by 0x411853: main (tincd.c:329) > > Index: event.c > =================================================================== > --- event.c (revision 369) > +++ event.c (working copy) > @@ -530,6 +530,7 @@ > ev->ev_arg = arg; > ev->ev_fd = fd; > ev->ev_events = events; > + ev->ev_res = 0; > ev->ev_flags = EVLIST_INIT; > ev->ev_ncalls = 0; > ev->ev_pncalls = NULL; > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From provos at citi.umich.edu Mon Jul 30 20:25:57 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 20:26:00 2007 Subject: [Libevent-users] compile patches for non-gcc In-Reply-To: <4689EABE.9050101@kneschke.de> References: <46715908.5050309@kneschke.de> <850f7cbe0706172155q2d612498u82e39518411a62e3@mail.gmail.com> <850f7cbe0706301211o171b969byf860fa2090d6cb05@mail.gmail.com> <4689EABE.9050101@kneschke.de> Message-ID: <850f7cbe0707301725x4bdd93a6kfb6822051a60c15e@mail.gmail.com> Hi Jan, I submitted almost all of these patches. The monotonic one had been fixed already by Scott Lamb and the have-select diff was not quite correct. So, I submitted something else. Please, let me know if this works for you now. Thank you, Niels. On 7/2/07, Jan Kneschke wrote: > Niels Provos wrote: > > Any chance to take a look at your patches vs trunk? > > Hi Niels, > > I checked the patches against trunk and a few issues are already fixed. > > * inline vs __inline > * libresolv on solaris > > It comes down to at least these patches: > > aix-monotonic > AIX has clock_gettime(), but only if you #define _XOPEN_SOURCE >= 500. > Without it, the defines are invisible which leads to a compile error. > Checking if the defines are available fixes it. > > have-select > sys/select.h is needed for the NFDBITS > > have-config > config.h is needed to get defines right. > > c99-vars > in pre-c99 variables have to be defined before code. This affects the > compile in gcc-2.95. > > c99-comments > // comments are available in C99 and GCC 3+ only. > > cflags > Setting CFLAGS directly breaks the passing of -m64, -xarch=v9, ... > from the command line to get a 64bit compile. Use AM_CFLAGS instead. > > > Thanks, > > Niels. > > > > cheers, > Jan > -- > jan: "Gee, Brain^WEric, what'd you wanna do tonight?" > eric: Same thing we do everynight: Take over the HelloWorld! > > From provos at citi.umich.edu Mon Jul 30 20:29:46 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 20:29:48 2007 Subject: [Libevent-users] conflict checked into subversion (tags/release-1.3b/libevent/configure.in) In-Reply-To: <46A0F44F.5020702@gratuitous.net> References: <46A0F44F.5020702@gratuitous.net> Message-ID: <850f7cbe0707301729h4c90642bt44919bbfdde4bdb1@mail.gmail.com> I think that this is a conflict in your local checkout. The configure.in in the repository seems fine. Niels. On 7/20/07, Elliot F wrote: > It appears that a subversion conflict got checked into subversion. Line > 4 of configure.in has the conflict listed, which b0rks the configure > script when run. Just an FYI. > > Thanks, > > Elliot > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From provos at citi.umich.edu Mon Jul 30 20:32:14 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 20:32:16 2007 Subject: [Libevent-users] fix for memory leak in evhttp_handle_chunked_read In-Reply-To: <46A8EEA6.8080503@gratuitous.net> References: <46A8EEA6.8080503@gratuitous.net> Message-ID: <850f7cbe0707301732j78021094xe9ff44b16242f0aa@mail.gmail.com> Submitted. Thank you, Niels. On 7/26/07, Elliot F wrote: > A fix for a small memory leak in http.c's evhttp_handle_chunked_read. > > Thanks, > > Elliot > > diff -Naur libevent-1.3b_orig/http.c libevent-1.3b_modified/http.c > --- libevent-1.3b_orig/http.c 2007-03-03 20:05:04.000000000 -0800 > +++ libevent-1.3b_modified/http.c 2007-07-26 11:46:33.000000000 -0700 > @@ -640,8 +640,10 @@ > if (p == NULL) > break; > /* the last chunk is on a new line? */ > - if (strlen(p) == 0) > + if (strlen(p) == 0) { > + free(p); > continue; > + } > req->ntoread = strtol(p, &endp, 16); > error = *p == '\0' || (*endp != '\0' && *endp != ' '); > free(p); > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > From elliotf-libevent at gratuitous.net Mon Jul 30 20:40:45 2007 From: elliotf-libevent at gratuitous.net (Elliot Foster) Date: Mon Jul 30 20:40:50 2007 Subject: [Libevent-users] conflict checked into subversion (tags/release-1.3b/libevent/configure.in) In-Reply-To: <850f7cbe0707301729h4c90642bt44919bbfdde4bdb1@mail.gmail.com> References: <46A0F44F.5020702@gratuitous.net> <850f7cbe0707301729h4c90642bt44919bbfdde4bdb1@mail.gmail.com> Message-ID: <46AE850D.4050905@gratuitous.net> I thought that might have been the case, but before I had sent the email, I cleaned it out and updated again. Going straight to the repo shows it best: http://levent.svn.sf.net/svnroot/levent/tags/release-1.3b/libevent/configure.in It's not a huge deal, but I thought you might want to know. At which repository are you looking? In case it's not clear, it's not in trunk, it's in tags/release-1.3b (from when you tagged it from 1.3a, it looks like.) Elliot Niels Provos wrote: > I think that this is a conflict in your local checkout. The > configure.in in the repository seems fine. > > Niels. > > On 7/20/07, Elliot F wrote: >> It appears that a subversion conflict got checked into subversion. Line >> 4 of configure.in has the conflict listed, which b0rks the configure >> script when run. Just an FYI. >> >> Thanks, >> >> Elliot >> _______________________________________________ >> Libevent-users mailing list >> Libevent-users@monkey.org >> http://monkey.org/mailman/listinfo/libevent-users >> >> From provos at citi.umich.edu Mon Jul 30 23:29:59 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Jul 30 23:30:12 2007 Subject: [Libevent-users] conflict checked into subversion (tags/release-1.3b/libevent/configure.in) In-Reply-To: <46AE850D.4050905@gratuitous.net> References: <46A0F44F.5020702@gratuitous.net> <850f7cbe0707301729h4c90642bt44919bbfdde4bdb1@mail.gmail.com> <46AE850D.4050905@gratuitous.net> Message-ID: <850f7cbe0707302029k764ec68bq739b7c890c95fcaf@mail.gmail.com> Bad me. Fixed now. Niels. On 7/30/07, Elliot Foster wrote: > I thought that might have been the case, but before I had sent the email, I cleaned it out and updated again. Going straight to the repo shows it best: > > http://levent.svn.sf.net/svnroot/levent/tags/release-1.3b/libevent/configure.in > > It's not a huge deal, but I thought you might want to know. At which repository are you looking? In case it's not clear, it's not in trunk, it's in tags/release-1.3b (from when you tagged it from 1.3a, it looks like.) > > Elliot > > Niels Provos wrote: > > I think that this is a conflict in your local checkout. The > > configure.in in the repository seems fine. > > > > Niels. > > > > On 7/20/07, Elliot F wrote: > >> It appears that a subversion conflict got checked into subversion. Line > >> 4 of configure.in has the conflict listed, which b0rks the configure > >> script when run. Just an FYI. > >> > >> Thanks, > >> > >> Elliot > >> _______________________________________________ > >> Libevent-users mailing list > >> Libevent-users@monkey.org > >> http://monkey.org/mailman/listinfo/libevent-users > >> > >> > > From provos at citi.umich.edu Tue Jul 31 00:09:20 2007 From: provos at citi.umich.edu (Niels Provos) Date: Tue Jul 31 00:09:23 2007 Subject: [Libevent-users] libevent-1.3c released Message-ID: <850f7cbe0707302109w291e6048s5ab2d4d0584f521f@mail.gmail.com> Hi, it has been awhile since the last release. 1.3c contains mostly small bug fixes and fixes for portability problems that people have submitted to the mailing list. You can find the new release at http://www.monkey.org/~provos/libevent/ Please, let me know if you have problems with this. Thank you, Niels.