From adrianc at ahost.co.za Tue May 1 01:16:46 2007 From: adrianc at ahost.co.za (Adrian Cuthbertson) Date: Tue May 1 01:15:16 2007 Subject: [Libevent-users] [PATCH] libevent-doxygen.diff In-Reply-To: <1177989356.18996.26.camel@voltaire> References: <1177989356.18996.26.camel@voltaire> Message-ID: <1177996606.29227.123.camel@chilli> > Here are the annotated header files and the Doxygen configuration file > that can be used to generate the libevent API reference manual found at Thank you Mark, the documentation is appreciated! From hkao-co at appliedminds.com Tue May 1 13:30:43 2007 From: hkao-co at appliedminds.com (harry) Date: Tue May 1 13:35:07 2007 Subject: [Libevent-users] event_init() and thread safety Message-ID: <20070501173039.GA11898@appliedminds.com> It's unsafe for two threads to call event_init() in parallel because it sets and returns the global current_base variable. If the first thread gets preempted by the second after calloc() but before the return, both calls will return the same value. My question is whether one should be concerned about the use of current_base in other parts of the code. For example, event_set() uses current_base while setting the priority. Is there any chance that a preemption will occur in the middle of retrieving the value of current_base resulting in an invalid pointer? Also, I assume that each process that loads libevent as a shared object must get its own copy of current_base, right? Harry From sgrimm at facebook.com Tue May 1 13:38:50 2007 From: sgrimm at facebook.com (Steven Grimm) Date: Tue May 1 13:38:39 2007 Subject: [Libevent-users] event_init() and thread safety In-Reply-To: <20070501173039.GA11898@appliedminds.com> References: <20070501173039.GA11898@appliedminds.com> Message-ID: <46377B2A.8000001@facebook.com> If you're calling event_init() more than once, you never want to call event_set() and other such functions. You want to call event_set_base() and pass in the handle you get back from event_init(). Using the current_base versions of the event calls in a multithreaded app (where you are using libevent from multiple threads in parallel) is almost certainly going to break your app. In the MT version of memcached I call event_init() in my startup thread and pass the handle to each of the worker threads I spawn. That way there's no chance of race conditions during initialization. -Steve harry wrote: > It's unsafe for two threads to call event_init() in parallel because > it sets and returns the global current_base variable. If the first > thread gets preempted by the second after calloc() but before the > return, both calls will return the same value. > > My question is whether one should be concerned about the use of > current_base in other parts of the code. For example, event_set() > uses current_base while setting the priority. Is there any chance > that a preemption will occur in the middle of retrieving the value of > current_base resulting in an invalid pointer? > > Also, I assume that each process that loads libevent as a shared > object must get its own copy of current_base, right? > > Harry > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > From hkao-co at appliedminds.com Tue May 1 14:45:37 2007 From: hkao-co at appliedminds.com (harry) Date: Tue May 1 14:47:46 2007 Subject: [Libevent-users] event_init() and thread safety In-Reply-To: <46377B2A.8000001@facebook.com> References: <20070501173039.GA11898@appliedminds.com> <46377B2A.8000001@facebook.com> Message-ID: <20070501184537.GA11997@appliedminds.com> On Tue, May 01, 2007 at 10:38:50AM -0700, Steven Grimm wrote: > If you're calling event_init() more than once, you never want to call > event_set() and other such functions. You want to call event_set_base() > and pass in the handle you get back from event_init(). Using the > current_base versions of the event calls in a multithreaded app (where > you are using libevent from multiple threads in parallel) is almost > certainly going to break your app. > > In the MT version of memcached I call event_init() in my startup thread > and pass the handle to each of the worker threads I spawn. That way > there's no chance of race conditions during initialization. Thanks for the response. I don't see an event_set_base() function. Do you mean event_base_set()? My understanding is that you call event_set() to initialize the event structure and then call event_base_set() to change the event's base from current_base to whatever you got back from event_init(). Is this incorrect? Harry From hkao-co at appliedminds.com Wed May 2 00:53:34 2007 From: hkao-co at appliedminds.com (harry) Date: Wed May 2 00:55:27 2007 Subject: [Libevent-users] event_base_loopexit() does not terminate loop Message-ID: <20070502045334.GA25305@appliedminds.com> I'm having trouble terminating event loops using event_base_loopexit(). The way it works, as I understand it, is by scheduling an event that sets the event_gotterm flag, which will cause the loop to quit after its current iteration. Here's the sequence of function calls: event_base_loopexit() event_once() evtimer_set() /* this sets ev_base to current_base */ event_add() This uses the event loop associated with current_base to run the callback (event_loopexit_cb()) instead of the base that was passed to event_base_loopexit(), which seems weird, but okay. However, if there's no loop running with current_base, event_loopexit_cb() never gets called so my loop never terminates. One could imagine this happening if you do something like: base_1 = event_init(); base_2 = event_init(); /* current_base is now base_2 */ event_base_loop(base_1, 0); /* somehow call event_base_loopexit(base_1, 0) now */ Why do we schedule a callback to set event_gotterm? This is a boolean flag and we only care if it's zero or non-zero, so why do we need to synchronize access to it? Harry From wouter at nlnetlabs.nl Wed May 2 02:50:18 2007 From: wouter at nlnetlabs.nl (Wouter Wijngaards) Date: Wed May 2 02:50:20 2007 Subject: [Libevent-users] event_base_loopexit() does not terminate loop In-Reply-To: <20070502045334.GA25305@appliedminds.com> References: <20070502045334.GA25305@appliedminds.com> Message-ID: <463834AA.7070209@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hm, I also fixed this thread race condition recently, try using more recent libevent or svn trunk. It has event_base_once() to use with event_base_loopexit(). Best regards, Wouter harry wrote: > I'm having trouble terminating event loops using event_base_loopexit(). > The way it works, as I understand it, is by scheduling an event that > sets the event_gotterm flag, which will cause the loop to quit after > its current iteration. Here's the sequence of function calls: > > event_base_loopexit() > event_once() > evtimer_set() /* this sets ev_base to current_base */ > event_add() > > This uses the event loop associated with current_base to run the > callback (event_loopexit_cb()) instead of the base that was passed to > event_base_loopexit(), which seems weird, but okay. However, if > there's no loop running with current_base, event_loopexit_cb() never > gets called so my loop never terminates. One could imagine this > happening if you do something like: > > base_1 = event_init(); > base_2 = event_init(); /* current_base is now base_2 */ > event_base_loop(base_1, 0); > /* somehow call event_base_loopexit(base_1, 0) now */ > > Why do we schedule a callback to set event_gotterm? This is a boolean > flag and we only care if it's zero or non-zero, so why do we need to > synchronize access to it? > > Harry > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGODSqkDLqNwOhpPgRAg43AJ0YxCNTNIRHptjoOnTjN/Tk/eMEaACfT3AV 1zjPqm+jB1zG9psUqRAW7g0= =1EXD -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Wed May 2 02:47:19 2007 From: wouter at nlnetlabs.nl (Wouter Wijngaards) Date: Wed May 2 03:08:31 2007 Subject: [Libevent-users] event_init() and thread safety In-Reply-To: <20070501184537.GA11997@appliedminds.com> References: <20070501173039.GA11898@appliedminds.com> <46377B2A.8000001@facebook.com> <20070501184537.GA11997@appliedminds.com> Message-ID: <463833F7.1070902@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 harry wrote: > On Tue, May 01, 2007 at 10:38:50AM -0700, Steven Grimm wrote: >> If you're calling event_init() more than once, you never want to call >> event_set() and other such functions. You want to call event_set_base() >> and pass in the handle you get back from event_init(). Using the >> current_base versions of the event calls in a multithreaded app (where >> you are using libevent from multiple threads in parallel) is almost >> certainly going to break your app. >> >> In the MT version of memcached I call event_init() in my startup thread >> and pass the handle to each of the worker threads I spawn. That way >> there's no chance of race conditions during initialization. > > Thanks for the response. I don't see an event_set_base() function. > Do you mean event_base_set()? My understanding is that you call > event_set() to initialize the event structure and then call > event_base_set() to change the event's base from current_base to > whatever you got back from event_init(). Is this incorrect? > Yes. Also, I fixed the event_init() thread problem in my thread-safety patch that was included a while ago. So, libevent trunk and possibly recent releases do not have this problem. I also solved several other thread problems, for loopexit() and for interrupt signal handling. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGODP3kDLqNwOhpPgRAjRlAKCQKQ8xndjrhtHTEbDQR8BPCSxY9QCfWHcD QKPtZ5I5RGBu0Y3jJhlCOD0= =cqpO -----END PGP SIGNATURE----- From david.w.h.chin at gmail.com Thu May 3 17:08:19 2007 From: david.w.h.chin at gmail.com (David Chin) Date: Thu May 3 17:08:33 2007 Subject: [Libevent-users] bug report Message-ID: Mac OS X 10.3.9 gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671) CFLAGS=-Os -mcpu=7450 -mtune=7450 -Wall I had to modify http.c by adding the following var definition to the function evhttp_get_body_length(): struct evhttp_connection *evcon = NULL; Without it, compilation with USE_DEBUG would fail because evcon is not defined in the function or arguments. Anyway, here's the output from "make verify": Running tests: KQUEUE test-eof: OKAY test-weof: OKAY test-time: OKAY regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl: 1800: 2610:a0:c779:b::d1ad:35b4 type: 2, count: 1, ttl: 3600: localhost OKAY DEVPOLL Skipping test POLL test-eof: OKAY test-weof: OKAY test-time: poll.c:282: failed assertion `pArray != (struct pollfd *) NULL' ./test.sh: line 70: 16166 Abort trap ./test-time >/dev/null FAILED regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl: 1800: 2610:a0:c779:b::d1ad:35b4 type: 2, count: 1, ttl: 3600: localhost OKAY SELECT test-eof: OKAY test-weof: OKAY test-time: OKAY regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl: 1800: 2610:a0:c779:b::d1ad:35b4 type: 2, count: 1, ttl: 3600: localhost OKAY RTSIG Skipping test EPOLL Skipping test This output and the full debug output can be seen here: http://david.w.h.chin.googlepages.com/verify_output.txt http://david.w.h.chin.googlepages.com/test-time_output.txt.gz Cheers, Dave -- 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 hkao-co at appliedminds.com Thu May 3 23:18:26 2007 From: hkao-co at appliedminds.com (Harry Kao) Date: Thu May 3 23:20:24 2007 Subject: [Libevent-users] [PATCH] fixes for better Solaris support Message-ID: <20070504031825.GA9553@appliedminds.com> Here's a patch against svn trunk to make libevent compile under Solaris using Sun Studio. The main changes are: - Changed __inline to inline. - Changed u_intX_t to uintX_t. This was changed in event_rpcgen.py as well. I don't use that script so I hope this was the right thing to do... - Added code to configure.in to detect the libraries needed to link in socket code. (This adds -lnsl -lresolv on Solaris.) - Fixed #includes in devpoll.c and evsignal.h to pull in required headers. - Removed volatile keyword from evsignal_info.evsignal_caught. I'm not sure why that was volatile in the first place. It still doesn't build very cleanly, but at least it builds... I've done limited testing on solaris-amd64, linux-amd64, linux-i386, mac-intel, and mac-ppc. I hope that more experienced eyes can look this over and make sure that I haven't broken anything. Thanks! Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris.diff Type: text/x-diff Size: 15728 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070503/febccc96/solaris-0001.bin From wouter at nlnetlabs.nl Fri May 4 02:21:08 2007 From: wouter at nlnetlabs.nl (Wouter Wijngaards) Date: Fri May 4 02:21:29 2007 Subject: [Libevent-users] [PATCH] fixes for better Solaris support In-Reply-To: <20070504031825.GA9553@appliedminds.com> References: <20070504031825.GA9553@appliedminds.com> Message-ID: <463AD0D4.8070206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Harry, I looked over your patch. * perhaps you should have configure detect __inline or inline. Some platforms do not understand plain 'inline' I believe. * the volatile keyword is needed because the signal handler sets this variable, then wakes up the eventloop. The eventloop reads the variable. Thus this variable is volatile for the eventloop, since a signal handler can change it at any time. Could you please add it back. Best regards, Wouter Harry Kao wrote: > Here's a patch against svn trunk to make libevent compile under > Solaris using Sun Studio. The main changes are: > > - Changed __inline to inline. > - Changed u_intX_t to uintX_t. This was changed in event_rpcgen.py > as well. I don't use that script so I hope this was the right > thing to do... > - Added code to configure.in to detect the libraries needed to link > in socket code. (This adds -lnsl -lresolv on Solaris.) > - Fixed #includes in devpoll.c and evsignal.h to pull in required > headers. > - Removed volatile keyword from evsignal_info.evsignal_caught. I'm > not sure why that was volatile in the first place. > > It still doesn't build very cleanly, but at least it builds... I've > done limited testing on solaris-amd64, linux-amd64, linux-i386, > mac-intel, and mac-ppc. I hope that more experienced eyes can look > this over and make sure that I haven't broken anything. Thanks! > > Harry > > Index: evsignal.h > =================================================================== > --- evsignal.h (revision 353) > +++ evsignal.h (working copy) > @@ -27,12 +27,14 @@ > #ifndef _EVSIGNAL_H_ > #define _EVSIGNAL_H_ > > +#include > + > struct evsignal_info { > struct event_list signalqueue; > struct event ev_signal; > int ev_signal_pair[2]; > int ev_signal_added; > - volatile sig_atomic_t evsignal_caught; > + sig_atomic_t evsignal_caught; > sig_atomic_t evsigcaught[NSIG]; > }; > void evsignal_init(struct event_base *); -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGOtDUkDLqNwOhpPgRAvlmAJ9RJ9QvfFT4yxkwe8AP5980kANUPgCePuR1 Y+ujgTyLTAx9Mz5MbHNTBl8= =hWlX -----END PGP SIGNATURE----- From hkao-co at appliedminds.com Fri May 4 02:55:27 2007 From: hkao-co at appliedminds.com (Harry Kao) Date: Fri May 4 02:57:22 2007 Subject: [Libevent-users] [PATCH] fixes for better Solaris support In-Reply-To: <463AD0D4.8070206@nlnetlabs.nl> References: <20070504031825.GA9553@appliedminds.com> <463AD0D4.8070206@nlnetlabs.nl> Message-ID: <20070504065527.GA26624@appliedminds.com> On Fri, May 04, 2007 at 08:21:08AM +0200, Wouter Wijngaards wrote: > Hi Harry, > > I looked over your patch. > * perhaps you should have configure detect __inline or inline. Some > platforms do not understand plain 'inline' I believe. configure.in already calls AC_C_INLINE, which should define "inline" to whatever keyword the compiler uses for that feature, or nothing if it is unsupported. > * the volatile keyword is needed because the signal handler sets this > variable, then wakes up the eventloop. The eventloop reads the variable. > Thus this variable is volatile for the eventloop, since a signal handler > can change it at any time. Could you please add it back. You're right, sorry about that. I didn't realize that variables accessed in a signal handler required "volatile." Here's an updated patch. Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris.diff Type: text/x-diff Size: 15706 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070503/4ca22839/solaris.bin From wouter at nlnetlabs.nl Fri May 4 03:00:31 2007 From: wouter at nlnetlabs.nl (Wouter Wijngaards) Date: Fri May 4 03:00:59 2007 Subject: [Libevent-users] [PATCH] fixes for better Solaris support In-Reply-To: <20070504065527.GA26624@appliedminds.com> References: <20070504031825.GA9553@appliedminds.com> <463AD0D4.8070206@nlnetlabs.nl> <20070504065527.GA26624@appliedminds.com> Message-ID: <463ADA0F.2090801@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harry Kao wrote: > configure.in already calls AC_C_INLINE, which should define "inline" > to whatever keyword the compiler uses for that feature, or nothing if > it is unsupported. > > You're right, sorry about that. I didn't realize that variables > accessed in a signal handler required "volatile." Here's an updated > patch. > Great thanks for the quick fix! Wouter. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGOtoPkDLqNwOhpPgRAgybAJ9VpRHzGfwkBbihSSBNiO259J/hZACePY3a 2k/A+AeIQBHRP8akKsDuAww= =B3fV -----END PGP SIGNATURE----- From lightzook at yahoo.com Fri May 4 13:30:41 2007 From: lightzook at yahoo.com (light zoo) Date: Fri May 4 13:37:24 2007 Subject: [Libevent-users] libevent pub key to verify source? Message-ID: <901588.26832.qm@web63001.mail.re1.yahoo.com> Hi, Where is the public key used to sign libevent-1.3b source? Is it on a key server? Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From provos at citi.umich.edu Fri May 4 15:23:41 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri May 4 15:23:45 2007 Subject: [Libevent-users] libevent pub key to verify source? In-Reply-To: <901588.26832.qm@web63001.mail.re1.yahoo.com> References: <901588.26832.qm@web63001.mail.re1.yahoo.com> Message-ID: <850f7cbe0705041223hf733088mf58018861d4ca7eb@mail.gmail.com> It's on the key servers and on my home page at http://www.citi.umich.edu/u/provos/ Niels. On 5/4/07, light zoo wrote: > Hi, > > Where is the public key used to sign libevent-1.3b > source? Is it on a key server? > > Thanks > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From cktan at greenplum.com Fri May 4 17:23:55 2007 From: cktan at greenplum.com (CK Tan) Date: Fri May 4 17:24:14 2007 Subject: [Libevent-users] patch to compile under solaris 10 Message-ID: <9E220900-1BFC-4FE7-8BD7-AA65026700B4@greenplum.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-solaris-patch Type: application/octet-stream Size: 8578 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070504/a25f8c2e/libevent-solaris-patch.obj -------------- next part -------------- From slamb at slamb.org Fri May 4 17:31:01 2007 From: slamb at slamb.org (Scott Lamb) Date: Fri May 4 17:31:09 2007 Subject: [Libevent-users] [PATCH] fixes for better Solaris support In-Reply-To: <20070504031825.GA9553@appliedminds.com> References: <20070504031825.GA9553@appliedminds.com> Message-ID: <934CBD78-98AE-43F5-8107-D46D59BA43BC@slamb.org> On May 3, 2007, at 8:18 PM, Harry Kao wrote: > - Changed u_intX_t to uintX_t. This was changed in event_rpcgen.py > as well. I don't use that script so I hope this was the right > thing to do... This sort of question is why it would be nice to have a buildbot installation with a bunch of different platforms. You'd just try the change, see if it breaks anywhere else. Frustrating - I had one set up, but first there were a bunch of memory limit problems with my server, then when I got that fixed, I lost most of the platforms because sourceforge shut down their compile farm. I've done the work to configure it for libevent as well as a project of my own, but it's not doing much good now for lack of machines. -- Scott Lamb From clayne at anodized.com Tue May 8 11:26:06 2007 From: clayne at anodized.com (Christopher Layne) Date: Tue May 8 11:26:24 2007 Subject: [Libevent-users] EV_PERSIST behavior Message-ID: <20070508152606.GS9189@ns1.anodized.com> 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... #include #include #include #include #include #include int pfd[2]; int persist[2]; struct event e; void rp(int fd, short event, void *p) { struct timeval tv = { 4, 0 }; time_t tn, *t = p; char c; tn = time(NULL); fprintf(stderr, "event callback, tdiff == %lu\n", tn - *t); if (event == EV_TIMEOUT) { fprintf(stderr, "timeout\n"); if (!persist[1]) event_add(&e, &tv); return; } else if (!persist[0]) { event_add(&e, &tv); } read(fd, &c, 1); fprintf(stderr, "writing to pipe\n"); write(pfd[1], ".", 1); sleep(1); return; } int main(int argc, char **argv) { struct timeval tv = { 4, 0 }; time_t t = time(NULL); pipe(pfd); write(pfd[1], ".", 1); persist[0] = argc > 1 ? EV_PERSIST : 0; persist[1] = argc > 2 ? 1 : 0; event_init(); event_set(&e, pfd[0], EV_READ | persist[0], rp, &t); event_add(&e, &tv); event_dispatch(); return 0; } $ gcc -o evs evs.c -levent 1. Here, we schedule an event and continually reschedule it upon the event firing. No timeout ever occurs because we are writing to the pipe every second. This seems like intuitive and normal behavior to me, with regards to timeouts (they never occur because we're writing): $ ./evs event callback, tdiff == 0 writing to pipe event callback, tdiff == 1 writing to pipe event callback, tdiff == 2 writing to pipe event callback, tdiff == 3 writing to pipe event callback, tdiff == 4 writing to pipe event callback, tdiff == 5 writing to pipe event callback, tdiff == 6 writing to pipe ^C 2. Here, we set EV_PERSIST, write an initial byte and then write to the pipe just like the previous example. However the part that seems entirely unintuitive to me is that a timeout event is being fired almost as if the timeout was based on absolute time. I would think that it would be expected behavior that if one were to set a timeout with event_set(), the timeout will only be fired if the event does not occur within the specified timeout period - just as if you were to be doing a typical "tv.tv_sec = tout; ret = select(..., &tv);" loop. But that idiom is not what is followed when using EV_PERSIST. The timeout occurs anyways, even if a read event is continuously being fired. What am I missing here? $ ./evs p event callback, tdiff == 0 writing to pipe event callback, tdiff == 1 writing to pipe event callback, tdiff == 2 writing to pipe event callback, tdiff == 3 writing to pipe event callback, tdiff == 4 timeout event callback, tdiff == 4 writing to pipe event callback, tdiff == 5 writing to pipe event callback, tdiff == 6 writing to pipe event callback, tdiff == 7 writing to pipe event callback, tdiff == 8 timeout event callback, tdiff == 8 writing to pipe event callback, tdiff == 9 writing to pipe ^C 3. event_dispatch() will return if we do not reschedule the event after a timeout occurs, even with EV_PERSIST. I don't have any issue with this, but it did surprise me when I first started using the library. $ ./evs p p event callback, tdiff == 0 writing to pipe event callback, tdiff == 1 writing to pipe event callback, tdiff == 2 writing to pipe event callback, tdiff == 3 writing to pipe event callback, tdiff == 4 timeout $ 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. -cl From oz at nixil.net Tue May 8 16:53:17 2007 From: oz at nixil.net (Phil Oleson) Date: Tue May 8 16:53:33 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <20070508152606.GS9189@ns1.anodized.com> References: <20070508152606.GS9189@ns1.anodized.com> Message-ID: <4640E33D.7080103@nixil.net> 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. From provos at citi.umich.edu Tue May 8 17:03:17 2007 From: provos at citi.umich.edu (Niels Provos) Date: Tue May 8 17:03:20 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <4640E33D.7080103@nixil.net> References: <20070508152606.GS9189@ns1.anodized.com> <4640E33D.7080103@nixil.net> Message-ID: <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> On 5/8/07, Phil Oleson 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. From clayne at anodized.com Tue May 8 21:10:29 2007 From: clayne at anodized.com (Christopher Layne) Date: Tue May 8 21:10:40 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> References: <20070508152606.GS9189@ns1.anodized.com> <4640E33D.7080103@nixil.net> <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> Message-ID: <20070509011029.GV9189@ns1.anodized.com> On Tue, May 08, 2007 at 02:03:17PM -0700, Niels Provos wrote: > On 5/8/07, Phil Oleson 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 From william at 25thandClement.com Tue May 8 21:38:51 2007 From: william at 25thandClement.com (William Ahern) Date: Tue May 8 21:38:56 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <20070509011029.GV9189@ns1.anodized.com> References: <20070508152606.GS9189@ns1.anodized.com> <4640E33D.7080103@nixil.net> <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> <20070509011029.GV9189@ns1.anodized.com> Message-ID: <20070509013851.GA27304@wilbur.25thandClement.com> 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 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. From clayne at anodized.com Tue May 8 21:44:06 2007 From: clayne at anodized.com (Christopher Layne) Date: Tue May 8 21:44:15 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <20070509013851.GA27304@wilbur.25thandClement.com> References: <20070508152606.GS9189@ns1.anodized.com> <4640E33D.7080103@nixil.net> <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> <20070509011029.GV9189@ns1.anodized.com> <20070509013851.GA27304@wilbur.25thandClement.com> Message-ID: <20070509014406.GW9189@ns1.anodized.com> 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 From oz at nixil.net Wed May 9 17:13:00 2007 From: oz at nixil.net (Phil Oleson) Date: Wed May 9 17:13:20 2007 Subject: [Libevent-users] EV_PERSIST behavior In-Reply-To: <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> References: <20070508152606.GS9189@ns1.anodized.com> <4640E33D.7080103@nixil.net> <850f7cbe0705081403s78c9771ei2c0bc1a081abe229@mail.gmail.com> Message-ID: <4642395C.1070300@nixil.net> Niels Provos wrote: > On 5/8/07, Phil Oleson 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. From jim at yonan.net Wed May 9 22:07:26 2007 From: jim at yonan.net (James Yonan) Date: Wed May 9 22:07:34 2007 Subject: [Libevent-users] HTTP proxy based on evhttp layer? Message-ID: <46427E5E.1000502@yonan.net> I'd like to know if anyone has developed a simple HTTP proxy based on the evhttp layer? This would be extremely useful as well as provide a great real-world example of evhttp usage. Thanks, James From chengzhong at staff.sina.com.cn Wed May 9 23:40:54 2007 From: chengzhong at staff.sina.com.cn (chengzhong) Date: Thu May 10 00:40:55 2007 Subject: [Libevent-users] BUG report about evhttp_htmlescape() in evhttp (libevent-1.3b) References: <20070504031825.GA9553@appliedminds.com> <463AD0D4.8070206@nlnetlabs.nl> <20070504065527.GA26624@appliedminds.com> Message-ID: <008201c792b5$0345f240$b80ada0a@PC300772505221> Hi All, If my inport is: char *html = "&"; when i do evhttp_htmlescape(html); I will get "&amp;" I'm not sure it is a bug or not , but it really bother me... From provos at citi.umich.edu Thu May 10 00:46:43 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu May 10 00:46:46 2007 Subject: [Libevent-users] BUG report about evhttp_htmlescape() in evhttp (libevent-1.3b) In-Reply-To: <008201c792b5$0345f240$b80ada0a@PC300772505221> References: <20070504031825.GA9553@appliedminds.com> <463AD0D4.8070206@nlnetlabs.nl> <20070504065527.GA26624@appliedminds.com> <008201c792b5$0345f240$b80ada0a@PC300772505221> Message-ID: <850f7cbe0705092146r3916791ewbdbe3c8f26880cc3@mail.gmail.com> That's exactly what it's supposed to do. Niels. On 5/9/07, chengzhong wrote: > Hi All, > If my inport is: > char *html = "&"; > > when i do > evhttp_htmlescape(html); > I will get "&amp;" > > I'm not sure it is a bug or not , but it really bother me... > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From liusifan at 21cn.com Thu May 10 05:43:17 2007 From: liusifan at 21cn.com (liusifan) Date: Thu May 10 05:43:39 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: <200705101743170317034@21cn.com> SGksIGFsbA0KDQpTUFNlcnZlciAwLjIuMSBpcyByZWxlYXNlZCAuIFRoaXMgcmVsZWFzZSBpbmNs dWRlIGFuIGVtYmVkZGVkIGh0dHAgc2VydmVyIGJ1aWx0IHVwb24gc3BzZXJ2ZXIuDQoNCllvdSBj YW4gZ2V0IHRoZSBjb2RlIGZyb20gdGhlIFNQU2VydmVyIGhvbWUgcGFnZToNCmh0dHA6Ly9jb2Rl Lmdvb2dsZS5jb20vcC9zcHNlcnZlci8NCmh0dHA6Ly9zcHNlcnZlci5nb29nbGVjb2RlLmNvbS9m aWxlcy9zcHNlcnZlci0wLjIuMS5zcmMudGFyLmd6CQkNCg0KYmVzdCByZWdhcmRzLA0KCQkgDQqh oaGhoaGhoaGhoaGhoaGhbGl1c2lmYW4NCqGhoaGhoaGhoaGhoaGhoaFsaXVzaWZhbkAyMWNuLmNv bQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA3LTA1LTEwDQoNCg0K From liusifan at 21cn.com Thu May 10 05:46:44 2007 From: liusifan at 21cn.com (liusifan) Date: Thu May 10 05:46:59 2007 Subject: [Libevent-users] BUG report about evhttp_htmlescape() in evhttp(libevent-1.3b) References: <20070504031825.GA9553@appliedminds.com>, <463AD0D4.8070206@nlnetlabs.nl>, <20070504065527.GA26624@appliedminds.com>, <008201c792b5$0345f240$b80ada0a@PC300772505221> Message-ID: <200705101746421710943@21cn.com> SGksDQoNClBsZWFzZSBsb29rIGF0IHRoZSBjb21tZW50IG9mIHRoZSBmdW5jdGlvbjoNCg0KLyoN CiAqIFJlcGxhY2VzIDwsID4sICIsICcgYW5kICYgd2l0aCAmbHQ7LCAmZ3Q7LCAmcXVvdDssDQog KiAmIzAzOTsgYW5kICZhbXA7IGNvcnJlc3BvbmRpbmdseS4NCiAqDQogKiBUaGUgcmV0dXJuZWQg c3RyaW5nIG5lZWRzIHRvIGJlIGZyZWVkIGJ5IHRoZSBjYWxsZXIuDQogKi8NCg0KY2hhciAqDQpl dmh0dHBfaHRtbGVzY2FwZShjb25zdCBjaGFyICpodG1sKQ0KDQoNCiANCgkJCQkgDQqhoaGhoaGh oaGhoaGhoaGhbGl1c2lmYW4NCqGhoaGhoaGhoaGhoaGhoaFsaXVzaWZhbkAyMWNuLmNvbQ0KoaGh oaGhoaGhoaGhoaGhoaGhoaEyMDA3LTA1LTEwDQoNCj4+PkhpIEFsbCwNCj4gICAgSWYgbXkgaW5w b3J0IGlzOg0KPiAgICBjaGFyICpodG1sID0gIiZhbXA7IjsNCj4NCj4gICAgd2hlbiBpIGRvDQo+ ICAgIGV2aHR0cF9odG1sZXNjYXBlKGh0bWwpOw0KPiAgICBJIHdpbGwgZ2V0ICImYW1wO2FtcDsi DQo+DQo+ICAgIEknbSBub3Qgc3VyZSBpdCBpcyBhIGJ1ZyBvciBub3QgLCBidXQgaXQgcmVhbGx5 IGJvdGhlciBtZS4uLg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+TGliZXZlbnQtdXNlcnMgbWFpbGluZyBsaXN0DQo+TGliZXZlbnQtdXNlcnNAbW9u a2V5Lm9yZw0KPmh0dHA6Ly9tb25rZXkub3JnL21haWxtYW4vbGlzdGluZm8vbGliZXZlbnQtdXNl cnMNCj4NCj4NCg0KPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkN Cg0K From elliotf-libevent at gratuitous.net Thu May 10 12:31:41 2007 From: elliotf-libevent at gratuitous.net (Elliot F) Date: Thu May 10 12:31:59 2007 Subject: [Libevent-users] HTTP proxy based on evhttp layer? In-Reply-To: <46427E5E.1000502@yonan.net> References: <46427E5E.1000502@yonan.net> Message-ID: <464348ED.3000902@gratuitous.net> James Yonan wrote: > I'd like to know if anyone has developed a simple HTTP proxy based on > the evhttp layer? > > This would be extremely useful as well as provide a great real-world > example of evhttp usage. I can't find the mailing list announcement, but Niels wrote an HTTP proxy based on libevent: http://www.spybye.org/ He cited "providing an example of libevent http layer usage" as one of his reasons for writing it, but I can't find where he announced it. Elliot F From ycrux at club-internet.fr Thu May 10 12:55:16 2007 From: ycrux at club-internet.fr (Ycrux) Date: Thu May 10 12:55:20 2007 Subject: [Libevent-users] A server framework library based on In-Reply-To: <200705101743170317034@21cn.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>, <200705101743170317034@21cn.com> Message-ID: <46434E74.2080505@club-internet.fr> Hi Liusifan! $ svn checkout http://spserver.googlecode.com/svn/trunk/ spserv && cd spserver spserver $ make gcc -Wall -D_REENTRANT -D_GNU_SOURCE -g -I../libevent/ -c sputils.cpp -o sputils.o gcc -Wall -D_REENTRANT -D_GNU_SOURCE -g -I../libevent/ -c spthreadpool.cpp -o spthreadpool.o gcc -Wall -D_REENTRANT -D_GNU_SOURCE -g -I../libevent/ -c event_msgqueue.c -o event_msgqueue.o event_msgqueue.c:18:20: config.h: No such file or directory make: *** [event_msgqueue.o] Error 1 The "config.h" u*is missing ;-) cheers Youn?s liusifan a ?crit : > Hi, all > > SPServer 0.2.1 is released . This release include an embedded http server built upon spserver. > > You can get the code from the SPServer home page: > http://code.google.com/p/spserver/ > http://spserver.googlecode.com/files/spserver-0.2.1.src.tar.gz > > best regards, > > ????????????????liusifan > ????????????????liusifan@21cn.com > ????????????????????2007-05-10 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > From liusifan at 21cn.com Thu May 10 19:40:35 2007 From: liusifan at 21cn.com (liusifan) Date: Thu May 10 19:40:59 2007 Subject: [Libevent-users] A server framework library based on 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>, , <200705101743170317034@21cn.com>, <46434E74.2080505@club-internet.fr> Message-ID: <200705110740347817531@21cn.com> SGmjrFljcnV4DQoNClBsZWFzZSByZWFkIHRoZSBzcHNlcnZlci9SRUFETUUgZmlsZS4NCg0KMi5C dWlsZGluZw0KDQpCZWZvcmUgYnVpbGRpbmcgc3BzZXJ2ZXIsIGxpYmV2ZW50IG11c3QgYmVlbiBp bnN0YWxsZWQuIFRlc3Qgd2l0aCBsaWJldmVudCAxLjEgYW5kIDEuMi4NCg0KWW91IGNhbiBkb253 bG9hZCBsaWJldmVudCBmcm9tIGl0cyBob21lIHBhZ2U6DQoNCiAgICAgICAgaHR0cDovL3d3dy5t b25rZXkub3JnL35wcm92b3MvbGliZXZlbnQvDQoNCkVkaXQgc3BzZXJ2ZXIvTWFrZWZpbGUgdG8g c3BlY2lmeSB0aGUgcGF0aCBvZiBsaWJldmVudDoNCg0KICAgICAgICBMSUJFVkVOVF9JTkNMID0g LUk8cGF0aF90b19saWJldmVudF9pbmNsdWRlPg0KICAgICAgICBMSUJFVkVOVF9MSUIgID0gLUw8 cGF0aF90b19saWJldmVudF9saWJyYXJ5PiAtbGV2ZW50DQoNCg0KDQpiZXN0IHJlZ2FyZKOsDQog DQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoWxpdXNpZmFuDQqhoaGhoaGhoaGhoaGhoaGhbGl1c2lm YW5AMjFjbi5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNy0wNS0xMQ0KDQo9PT09PT09IDIw MDctMDUtMTEgMDA6NTk6NTYgxPrU2sC00MXW0NC0tcCjuj09PT09PT0NCg0KPj4+SGkgTGl1c2lm YW4hDQo+DQo+JCBzdm4gY2hlY2tvdXQgaHR0cDovL3Nwc2VydmVyLmdvb2dsZWNvZGUuY29tL3N2 bi90cnVuay8gc3BzZXJ2ICYmIGNkIA0KPnNwc2VydmVyDQo+c3BzZXJ2ZXIgJCAgbWFrZQ0KPmdj YyAtV2FsbCAtRF9SRUVOVFJBTlQgLURfR05VX1NPVVJDRSAtZyAtSS4uL2xpYmV2ZW50LyAtYyBz cHV0aWxzLmNwcCAtbyANCj5zcHV0aWxzLm8NCj5nY2MgLVdhbGwgLURfUkVFTlRSQU5UIC1EX0dO VV9TT1VSQ0UgLWcgLUkuLi9saWJldmVudC8gLWMgDQo+c3B0aHJlYWRwb29sLmNwcCAtbyBzcHRo cmVhZHBvb2wubw0KPmdjYyAtV2FsbCAtRF9SRUVOVFJBTlQgLURfR05VX1NPVVJDRSAtZyAtSS4u L2xpYmV2ZW50LyAtYyANCj5ldmVudF9tc2dxdWV1ZS5jIC1vIGV2ZW50X21zZ3F1ZXVlLm8NCj5l dmVudF9tc2dxdWV1ZS5jOjE4OjIwOiBjb25maWcuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eQ0KPm1ha2U6ICoqKiBbZXZlbnRfbXNncXVldWUub10gRXJyb3IgMQ0KPg0KPlRoZSAiY29uZmln LmgiIHUqaXMgbWlzc2luZyA7LSkNCj4NCj5jaGVlcnMNCj5Zb3Vu6HMNCj4NCj5saXVzaWZhbiBh IOljcml0IDoNCj4+IEhpLCBhbGwNCj4+DQo+PiBTUFNlcnZlciAwLjIuMSBpcyByZWxlYXNlZCAu IFRoaXMgcmVsZWFzZSBpbmNsdWRlIGFuIGVtYmVkZGVkIGh0dHAgc2VydmVyIGJ1aWx0IHVwb24g c3BzZXJ2ZXIuDQo+Pg0KPj4gWW91IGNhbiBnZXQgdGhlIGNvZGUgZnJvbSB0aGUgU1BTZXJ2ZXIg aG9tZSBwYWdlOg0KPj4gaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3Nwc2VydmVyLw0KPj4gaHR0 cDovL3Nwc2VydmVyLmdvb2dsZWNvZGUuY29tL2ZpbGVzL3Nwc2VydmVyLTAuMi4xLnNyYy50YXIu Z3oJCQ0KPj4NCj4+IGJlc3QgcmVnYXJkcywNCj4+IAkJIA0KPj4goaGhoaGhoaGhoaGhoaGhoWxp dXNpZmFuDQo+PiChoaGhoaGhoaGhoaGhoaGhbGl1c2lmYW5AMjFjbi5jb20NCj4+IKGhoaGhoaGh oaGhoaGhoaGhoaGhMjAwNy0wNS0xMA0KPj4NCj4+DQo+PiAgIA0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IExpYmV2ZW50LXVzZXJzIG1haWxpbmcgbGlzdA0KPj4gTGliZXZlbnQtdXNlcnNAbW9ua2V5 Lm9yZw0KPj4gaHR0cDovL21vbmtleS5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJldmVudC11c2Vy cw0KPj4gICANCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPkxpYmV2ZW50LXVzZXJzIG1haWxpbmcgbGlzdA0KPkxpYmV2ZW50LXVzZXJzQG1vbmtl eS5vcmcNCj5odHRwOi8vbW9ua2V5Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpYmV2ZW50LXVzZXJz DQo+DQo+DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoN Cg== From liusifan at 21cn.com Thu May 10 19:54:24 2007 From: liusifan at 21cn.com (liusifan) Date: Thu May 10 19:55:03 2007 Subject: [Libevent-users] HTTP proxy based on evhttp layer? References: <46427E5E.1000502@yonan.net>, <464348ED.3000902@gratuitous.net> Message-ID: <200705110754241873239@21cn.com> SGmjrEVsbGlvdA0KDQpOaWVscyBhbm5vdW5jZXMgaGVyZQ0KDQpodHRwOi8vbW9ua2V5bWFpbC5v cmcvYXJjaGl2ZXMvbGliZXZlbnQtdXNlcnMvMjAwNy1GZWJydWFyeS8wMDA1NDcuaHRtbA0KDQpi ZXN0IHJlZ2FyZHOjrA0Kc3RlcGhlbg0KDQoNCj09PT09PT0gMjAwNy0wNS0xMSAwMDozNjoyNyDE +tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+Pj5KYW1lcyBZb25hbiB3cm90ZToNCj4+IEknZCBs aWtlIHRvIGtub3cgaWYgYW55b25lIGhhcyBkZXZlbG9wZWQgYSBzaW1wbGUgSFRUUCBwcm94eSBi YXNlZCBvbiANCj4+IHRoZSBldmh0dHAgbGF5ZXI/DQo+PiANCj4+IFRoaXMgd291bGQgYmUgZXh0 cmVtZWx5IHVzZWZ1bCBhcyB3ZWxsIGFzIHByb3ZpZGUgYSBncmVhdCByZWFsLXdvcmxkIA0KPj4g ZXhhbXBsZSBvZiBldmh0dHAgdXNhZ2UuDQo+DQo+SSBjYW4ndCBmaW5kIHRoZSBtYWlsaW5nIGxp c3QgYW5ub3VuY2VtZW50LCBidXQgTmllbHMgd3JvdGUgYW4gSFRUUCANCj5wcm94eSBiYXNlZCBv biBsaWJldmVudDoNCj4NCj5odHRwOi8vd3d3LnNweWJ5ZS5vcmcvDQo+DQo+SGUgY2l0ZWQgInBy b3ZpZGluZyBhbiBleGFtcGxlIG9mIGxpYmV2ZW50IGh0dHAgbGF5ZXIgdXNhZ2UiIGFzIG9uZSBv ZiANCj5oaXMgcmVhc29ucyBmb3Igd3JpdGluZyBpdCwgYnV0IEkgY2FuJ3QgZmluZCB3aGVyZSBo ZSBhbm5vdW5jZWQgaXQuDQo+DQo+RWxsaW90IEYNCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPkxpYmV2ZW50LXVzZXJzIG1haWxpbmcgbGlzdA0KPkxp YmV2ZW50LXVzZXJzQG1vbmtleS5vcmcNCj5odHRwOi8vbW9ua2V5Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xpYmV2ZW50LXVzZXJzDQo+DQo+DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9 ID0gPSA9ID0gPQ0KCQkJDQoNCg== From christopher at baus.net Thu May 10 20:08:03 2007 From: christopher at baus.net (Christopher Baus) Date: Thu May 10 20:08:06 2007 Subject: [Libevent-users] HTTP proxy based on evhttp layer? In-Reply-To: <200705110754241873239@21cn.com> References: <46427E5E.1000502@yonan.net>, <464348ED.3000902@gratuitous.net> <200705110754241873239@21cn.com> Message-ID: <42782.12.146.21.162.1178842083.squirrel@webmail.tuffmail.net> > Hi??Elliot > > Niels announces here > > http://monkeymail.org/archives/libevent-users/2007-February/000547.html > > best regards?? > stephen > > > ======= 2007-05-11 00:36:27 ????????????????======= > >>>>James Yonan wrote: >>> I'd like to know if anyone has developed a simple HTTP proxy based on >>> the evhttp layer? I am probably going to move away from libevent to boost::asio, but if anybody is interested in a C++ reverse proxy based on libevent: https://baus.net/switchflow It's under the Boost license which is similar to MIT and BSD. Thanks, Chris From christopher at baus.net Thu May 10 20:17:50 2007 From: christopher at baus.net (Christopher Baus) Date: Thu May 10 20:17:52 2007 Subject: [Libevent-users] HTTP proxy based on evhttp layer? In-Reply-To: <42782.12.146.21.162.1178842083.squirrel@webmail.tuffmail.net> References: <46427E5E.1000502@yonan.net>, <464348ED.3000902@gratuitous.net> <200705110754241873239@21cn.com> <42782.12.146.21.162.1178842083.squirrel@webmail.tuffmail.net> Message-ID: <43758.12.146.21.162.1178842670.squirrel@webmail.tuffmail.net> > https://baus.net/switchflow Sorry make that: http://baus.net/switchflow From beyondkaoru at gmail.com Thu May 10 23:37:42 2007 From: beyondkaoru at gmail.com (beyondkaoru) Date: Thu May 10 23:37:50 2007 Subject: [Libevent-users] newbie question Message-ID: <4643E506.4070004@gmail.com> will callbacks from events ever interrupt each other? if i have a socket which gets data, so its event handler starts running the function i told it to, and data comes in on another socket, can i be sure that the second event's function won't start until the first one is finished? or would i have to introduce mutexes and/or semaphores? From liusifan at 21cn.com Fri May 11 04:12:38 2007 From: liusifan at 21cn.com (liusifan) Date: Fri May 11 04:12:57 2007 Subject: [Libevent-users] How do i make a multi-threaded libevent server? References: , Message-ID: <200705111612374215323@21cn.com> SGksIE1hcnRpbiBIZWRlbmZhbGsNCg0KPj4+T24gNC8xMi8wNywgQWRhbSBDaG91IDxhZGFtLmNo b3VAZ21haWwuY29tPiB3cm90ZToNCj4NCj4yLiBJZiB0aGUgcHJvY2Vzc2luZyBvZiBlYWNoIGNs aWVudCByZXF1ZXN0IHRha2VzIGxvbmcgdGltZSBhbmQgbWlnaHQNCj5ibG9jayBvdGhlciByZXF1 ZXN0cywgdHJ5IHRvIGJyZWFrIGl0IHVwIGludG8gY2h1bmtzLiBBZnRlciBlYWNoIGNodW5rDQo+ eW91IHNjaGVkdWxlIGFub3RoZXIgb25lICh3aXRoIGEgdGltZXIgb2YgMCBzZWNvbmRzKSBhbmQg Z28gYmFjayB0bw0KPnRoZSBldmVudCBsb29wLg0KPg0KPkkndmUgaW1wbGVtZW50ZWQgdGhpcyBz dWNjZXNzZnVsbHkgZm9yIGEgcmVxdWVzdCB0aGF0IG5lZWRlZCBhIGZ1bGwNCj5maWxlc3lzdGVt IGRpcmVjdG9yeSB0cmVlIHRyYXZlcnNhbC4gRWFjaCBjaHVuay9pdGVyYXRpb24gd291bGQNCj50 cmF2ZXJzZSA1IGRpcmVjdG9yaWVzLCB0aGVuIHNjaGVkdWxlIGFub3RoZXIgY2h1bmsgYW5kIHJl dHVybiB0byB0aGUNCj5ldmVudCBsb29wLiBCYWNrIGluIHRoZSBldmVudCBsb29wIEkgd291bGQg dGhlbiBlaXRoZXIgcHJvY2VzcyBhbnkNCj5vdXRzdGFuZGluZyBzb2NrZXQgZXZlbnQsIG9yIGdv IGJhY2sgdG8gdGhlIGRpcmVjdG9yeSB0cmF2ZXJzYWwNCj5yZXF1ZXN0Lg0KPg0KDQpEbyB0aGUg Y2h1bmsgaXMgcHJvY2Vzc2VkIGluIHRoZSBpbnB1dCBjYWxsYmFjaywgdXNpbmcgdGhlIHNhbWUg c3RhY2sgb2YNCnRoZSBldmVudCBsb29wIHRocmVhZCA/DQpJZiB0aGUgY2h1bmsgbmVlZCB0byBl eGVjdXRlIGEgbXlzcWxfcmVhbF9xdWVyeSgpIGNhbGwsIGhvdyBjYW4gaSBkbyA/DQoNCkJlc3Qg cmVnYXJkc6OsDQoNCnN0ZXBoZW4NCjIwMDctMDUtMTEJCQkNCg0K From 404emailnotfound at gmail.com Fri May 11 04:22:25 2007 From: 404emailnotfound at gmail.com (Matt Pearson) Date: Fri May 11 04:22:28 2007 Subject: [Libevent-users] newbie question In-Reply-To: <4643E506.4070004@gmail.com> References: <4643E506.4070004@gmail.com> Message-ID: <706b4240705110122j68a0d1a8n85fdc50e4282f663@mail.gmail.com> On 5/10/07, beyondkaoru wrote: > > will callbacks from events ever interrupt each other? > > if i have a socket which gets data, so its event handler starts running > the function i told it to, and data comes in on another socket, can i be > sure that the second event's function won't start until the first one is > finished? or would i have to introduce mutexes and/or semaphores? Libevent is inherently single-threaded, so it cannot preempt other code that is running. Another callback will be issued only after you return from the callback, returning control to the event library. The fact that you don't have to worry about synchronization is one of the main reasons for using asynchronous I/O over individual threads. From provos at citi.umich.edu Fri May 11 11:46:42 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri May 11 11:46:47 2007 Subject: [Libevent-users] How do i make a multi-threaded libevent server? In-Reply-To: <461FC058.8060302@facebook.com> References: <461FC058.8060302@facebook.com> Message-ID: <850f7cbe0705110846m73d65e8bqd0f3655d43967198@mail.gmail.com> On 4/13/07, Steven Grimm wrote: > As for how to do it, my approach is documented on the libevent home page > (or rather, there's a link there to my explanation) so I won't repeat > myself. But I will say it's working well for us -- our memcached > instances are handling close to twice the request volume they used to be > able to handle when they were single-threaded, and they still have > plenty of capacity to spare. Hi Steven, I would really like to see measurements on that. Do you have any graphs that show the performance differences between single-threaded and multi-threaded implementation? As a general point, as more and more CPUs are multi-core now or provide hyper threading, you get better resource utilization by making your applications multi-threaded. Libevent allows you to run multiple event loops, so that you can have at least one per core. Niels. From slamb at slamb.org Fri May 11 14:19:01 2007 From: slamb at slamb.org (Scott Lamb) Date: Fri May 11 14:19:09 2007 Subject: [Libevent-users] How do i make a multi-threaded libevent server? In-Reply-To: <850f7cbe0705110846m73d65e8bqd0f3655d43967198@mail.gmail.com> References: <461FC058.8060302@facebook.com> <850f7cbe0705110846m73d65e8bqd0f3655d43967198@mail.gmail.com> Message-ID: <6AB34E6C-FBFF-4572-A5B8-D077315AF59E@slamb.org> On May 11, 2007, at 8:46 AM, Niels Provos wrote: > I would really like to see measurements on that. Do you have any > graphs that show the performance differences between single-threaded > and multi-threaded implementation? Speaking of which, I've been meaning to benchmark some single- threaded vs. multi-threaded libevent approaches for a while, but haven't really gotten around to working up appropriate benchmark software. But it occurs to me...you have those nice graphs on the libevent webpage of different implementations. What'd you use to make that? Maybe it could be adapted pretty easily. -- Scott Lamb From ben.rigas at interoptechnologies.com Fri May 11 15:12:00 2007 From: ben.rigas at interoptechnologies.com (Ben Rigas) Date: Fri May 11 15:12:21 2007 Subject: [Libevent-users] [Patch] evhttp fix Message-ID: <7C5FD379-4DD2-427A-9733-49ED46E9550E@interoptechnologies.com> We had an issue where we needed to evhttp_conneciton_free() inside the response callback, which caused an error with line 617 of http.c /* notify the user of the request */ (*req->cb)(req, req->cb_arg); /* if this was an outgoing request, we own and it's done. so free it */ if (evcon->flags & EVHTTP_CON_OUTGOING) { evhttp_request_free(req); } Since evcon was free'd in the callback, we got the error. My solution was to store the result of evcon->flags & EVHTTP_CON_OUTGOING before we make the callback. -------------- next part -------------- A non-text attachment was scrubbed... Name: http_fix.patch Type: application/octet-stream Size: 857 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070511/10abb7fb/http_fix.obj -------------- next part -------------- -Ben -- Ben Rigas Senior Software Engineer, InterOP Technologies (239) 425-3000 From provos at citi.umich.edu Sat May 12 03:13:25 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat May 12 03:13:29 2007 Subject: [Libevent-users] [Patch] evhttp fix In-Reply-To: <7C5FD379-4DD2-427A-9733-49ED46E9550E@interoptechnologies.com> References: <7C5FD379-4DD2-427A-9733-49ED46E9550E@interoptechnologies.com> Message-ID: <850f7cbe0705120013q250b3375r13cd116b51fb7c5d@mail.gmail.com> Thank you. I submitted the patch. Niels. On 5/11/07, Ben Rigas wrote: > We had an issue where we needed to evhttp_conneciton_free() inside > the response callback, which caused an error with line 617 of http.c > > /* notify the user of the request */ > (*req->cb)(req, req->cb_arg); > > /* if this was an outgoing request, we own and it's done. so > free it */ > if (evcon->flags & EVHTTP_CON_OUTGOING) { > evhttp_request_free(req); > } > > Since evcon was free'd in the callback, we got the error. > My solution was to store the result of evcon->flags & > EVHTTP_CON_OUTGOING before we make the callback. > > > > -Ben > > > -- > Ben Rigas > Senior Software Engineer, InterOP Technologies > (239) 425-3000 > > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > From provos at citi.umich.edu Sat May 12 12:12:34 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat May 12 12:12:39 2007 Subject: [Libevent-users] How do i make a multi-threaded libevent server? In-Reply-To: <6AB34E6C-FBFF-4572-A5B8-D077315AF59E@slamb.org> References: <461FC058.8060302@facebook.com> <850f7cbe0705110846m73d65e8bqd0f3655d43967198@mail.gmail.com> <6AB34E6C-FBFF-4572-A5B8-D077315AF59E@slamb.org> Message-ID: <850f7cbe0705120912q5130b182xe9deca2532d7c80e@mail.gmail.com> On 5/11/07, Scott Lamb wrote: > But it occurs to me...you have those nice graphs on the libevent > webpage of different implementations. What'd you use to make that? > Maybe it could be adapted pretty easily. I made the benchmark with the bench.c program that comes with libevent. Niels. From liusifan at 21cn.com Fri May 18 00:02:40 2007 From: liusifan at 21cn.com (liusifan) Date: Fri May 18 00:03:13 2007 Subject: [Libevent-users] How do i make a multi-threaded libevent server? References: , , <461FC058.8060302@facebook.com>, <850f7cbe0705110846m73d65e8bqd0f3655d43967198@mail.gmail.com>, <6AB34E6C-FBFF-4572-A5B8-D077315AF59E@slamb.org> Message-ID: <200705181202365009782@21cn.com> SGksIFNjb3R0IExhbWINCg0KSSd2ZSBtYWtlIGEgYmVuY2htYXJrIGZvciBzaW5nbGUtdGhyZWFk ZWQgdnMuIG11bHRpLXRocmVhZGVkIA0KbGliZXZlbnQgYXBwcm9hY2hlcy4gVGhlIHNpbmdsZS10 aHJlYWRlZCBwcm9ncmFtIGlzIG1lbWNhY2hlZCAxLjIuMC4NClRoZSBtdWx0aS10aHJlYWRlZCBw cm9ncmFtIGlzIHNwY2FjaGVkLg0KDQpzcGNhY2hlZCBpcyBhIHNlcnZlciB3aGljaCBpbXBsZW1l bnRzIG1lbWNhY2hlZCBwcm90b2NvbC4NCk1vcmUgZGV0YWlsIGFib3V0IHNwY2FjaGVkLCBwbGVh c2UgcmVmZXIgaXRzIGhvbWUgcGFnZToNCmh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9zcGNhY2hl ZC8NCg0KVXNpbmcgbWVtY2FjaGVkIGphdmEgY2xpZW50IGFzIGJlbmNobWFyayB0b29sOg0KaHR0 cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3NwY2FjaGVkL3dpa2kvYmVuY2htYXJrdG9vbA0KDQptZW1j YWNoZWQgMS4yLjAgaXMgYSBzaW5nbGUtdGhyZWFkZWQgZXZlbnQtZHJpdmVuIHByb2dyYW0uDQpz cGNhY2hlZCB1c2VzIGEgaGFsZi1zeW5jL2hhbGYtYXN5bmMgdGhyZWFkIHBvb2wsIGl0IGhhcyBh IG1haW4NCnRocmVhZCB0byBwcm9jZXNzIEkvTyBldmVudCwgYW5kIGEgd29ya2VyIHRocmVhZCB0 byBwcm9jZXNzDQp0aGUgcmVhbCByZXF1ZXN0Lg0KDQpUaGUgdGVzdCBlbnZpcm9tZW50IGlzIDoN CkhhcmR3YXJlOiBERUxMIDY0ME0gKCBDUFUgSW50ZWwgVDIzMDAsIFJBTSAxRyApDQpTb2Z0d2Fy ZTogd2luZG93cyB4cCANCiAgICAgICAgICB2bXdhcmUgNS41LjEgKCBhbGxvY2F0ZSAxMjhNIFJB TSApDQogICAgICAgICAgUmVkSGF0IDcuMihLZXJuZWwgMi40LjE4LTMpDQoNClRoZSB0ZXN0IHN0 ZXBzIGFyZToNCjEucmVzdGFydCB3aW5kb3dzIHhwIGFuZCB2bXdhcmUNCjIubGltaXQgbWVtY2Fj aGVkIGFuZCBzcGNhY2hlZCBib3RoIGNhbiBvbmx5IGtlZXAgMTg1ODA4IG9iamVjdHMNCjMuc3Rh cnQgbWVtY2FjaGVkIGFuZCBNZW1DYWNoZWRUaHJlYWRCZW5jaCANCiAgKCB0aGUgbWVtY2FjaGVk IGFuZCBiZW5jaG1hcmsgdG9vbCBydW4gb24gdGhlIHNhbWUgdm13YXJlICkNCiAgYmFzaCQgbWVt Y2FjaGVkIC1tIDk2DQo0LnN0b3AgbWVtY2FjaGVkLCBzdGFydCBzcGNhY2hlZCBhbmQgTWVtQ2Fj aGVkVGhyZWFkQmVuY2gNCiAgYmFzaCQgc3BjYWNoZWQgLWMgMTg1ODA4ICANCg0KVGhlIHRlc3Qg cmVzdWx0IGlzOg0KDQpGb3Igc2V0IG9wZXJhdGlvbjoNCm1lbWNhY2hlZCA6IHNwY2FjaGVkIC0t IDQwMDAgOiAyNjAwICggPiA0IHRocmVhZHMgKQ0KDQpGb3IgZ2V0IG9wZXJhdGlvbjoNCm1lbWNh Y2hlZCA6IHNwY2FjaGVkIC0tIDM1MDAgOiAyNDgwICggPiA0IHRocmVhZHMgKQ0KDQpEZXRhaWwg dGVzdCByZXN1bHQ6DQoNCm1lbWNhY2hlZA0KICBQSUQgVVNFUiAgICAgUFJJICBOSSAgU0laRSAg UlNTIFNIQVJFIFNUQVQgJUNQVSAlTUVNICAgVElNRSBDT01NQU5EDQoyMjY0MiB4eHh4eCAgICAg MTUgICAwICAxMDBNICA2ME0gIDU0ODggUyAgICAgMC4wIDQ5LjIgIDE5OjI3IG1lbWNhY2hlZA0K DQpiYXNoJCBqYXZhIGNvbS9kYW5nYS9NZW1DYWNoZWQvdGVzdC9NZW1DYWNoZWRUaHJlYWRCZW5j aCA1MDAwMDAgMCAxMTIxMSAxDQpUaHJlYWQgIHN0YXJ0ICAgcnVucyAgICBzZXQgdGltZShtcykg ICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAgICAgNTAwMDAwICAxNjg5MjQgICAgICAgICAg MTQ5MjM0DQogICAgICAgIFJlcVBlclNlY29uZCAgICBzZXQgLSAyOTU5ICAgICAgZ2V0IC0gMzM1 MA0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01lbUNhY2hlZC90ZXN0L01lbUNhY2hlZFRocmVh ZEJlbmNoIDI1MDAwMCAwIDExMjExIDINClRocmVhZCAgc3RhcnQgICBydW5zICAgIHNldCB0aW1l KG1zKSAgICBnZXQgdGltZShtcykNCk1haW4gICAgICAgICAgICA1MDAwMDAgIDEzNTA1MSAgICAg ICAgICAxNTM2MDANCiAgICAgICAgUmVxUGVyU2Vjb25kICAgIHNldCAtIDM3MDIgICAgICBnZXQg LSAzMjU1DQotLQ0KYmFzaCQgamF2YSBjb20vZGFuZ2EvTWVtQ2FjaGVkL3Rlc3QvTWVtQ2FjaGVk VGhyZWFkQmVuY2ggMTY2NjY2IDAgMTEyMTEgMw0KVGhyZWFkICBzdGFydCAgIHJ1bnMgICAgc2V0 IHRpbWUobXMpICAgIGdldCB0aW1lKG1zKQ0KTWFpbiAgICAgICAgICAgIDQ5OTk5OCAgMTQxMTIw ICAgICAgICAgIDE1NjU5MQ0KICAgICAgICBSZXFQZXJTZWNvbmQgICAgc2V0IC0gMzU0MyAgICAg IGdldCAtIDMxOTMNCi0tDQpiYXNoJCBqYXZhIGNvbS9kYW5nYS9NZW1DYWNoZWQvdGVzdC9NZW1D YWNoZWRUaHJlYWRCZW5jaCAxMjUwMDAgMCAxMTIxMSA0DQpUaHJlYWQgIHN0YXJ0ICAgcnVucyAg ICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAgICAgNTAwMDAwICAx MjMzNzAgICAgICAgICAgMTQyMTY5DQogICAgICAgIFJlcVBlclNlY29uZCAgICBzZXQgLSA0MDUy ICAgICAgZ2V0IC0gMzUxNg0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01lbUNhY2hlZC90ZXN0 L01lbUNhY2hlZFRocmVhZEJlbmNoIDEwMDAwMCAwIDExMjExIDUNClRocmVhZCAgc3RhcnQgICBy dW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZShtcykNCk1haW4gICAgICAgICAgICA1MDAw MDAgIDEyNDExMSAgICAgICAgICAxNDIxNDcNCiAgICAgICAgUmVxUGVyU2Vjb25kICAgIHNldCAt IDQwMjggICAgICBnZXQgLSAzNTE3DQotLQ0KYmFzaCQgamF2YSBjb20vZGFuZ2EvTWVtQ2FjaGVk L3Rlc3QvTWVtQ2FjaGVkVGhyZWFkQmVuY2ggODMzMzMgMCAxMTIxMSA2DQpUaHJlYWQgIHN0YXJ0 ICAgcnVucyAgICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAgICAg NDk5OTk4ICAxMjM1MDQgICAgICAgICAgMTQxODU3DQogICAgICAgIFJlcVBlclNlY29uZCAgICBz ZXQgLSA0MDQ4ICAgICAgZ2V0IC0gMzUyNA0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01lbUNh Y2hlZC90ZXN0L01lbUNhY2hlZFRocmVhZEJlbmNoIDcxNDI4IDAgMTEyMTEgNw0KVGhyZWFkICBz dGFydCAgIHJ1bnMgICAgc2V0IHRpbWUobXMpICAgIGdldCB0aW1lKG1zKQ0KTWFpbiAgICAgICAg ICAgIDQ5OTk5NiAgMTI0NzY3ICAgICAgICAgIDE0MjkzOQ0KICAgICAgICBSZXFQZXJTZWNvbmQg ICAgc2V0IC0gNDAwNyAgICAgIGdldCAtIDM0OTcNCi0tDQpiYXNoJCBqYXZhIGNvbS9kYW5nYS9N ZW1DYWNoZWQvdGVzdC9NZW1DYWNoZWRUaHJlYWRCZW5jaCA2MjUwMCAwIDExMjExIDgNClRocmVh ZCAgc3RhcnQgICBydW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZShtcykNCk1haW4gICAg ICAgICAgICA1MDAwMDAgIDEyNDc0NiAgICAgICAgICAxNDI4ODcNCiAgICAgICAgUmVxUGVyU2Vj b25kICAgIHNldCAtIDQwMDggICAgICBnZXQgLSAzNDk5DQotLQ0KYmFzaCQgamF2YSBjb20vZGFu Z2EvTWVtQ2FjaGVkL3Rlc3QvTWVtQ2FjaGVkVGhyZWFkQmVuY2ggNTU1NTUgMCAxMTIxMSA5DQpU aHJlYWQgIHN0YXJ0ICAgcnVucyAgICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpNYWlu ICAgICAgICAgICAgNDk5OTk1ICAxMjQ4MjEgICAgICAgICAgMTQzMjc4DQogICAgICAgIFJlcVBl clNlY29uZCAgICBzZXQgLSA0MDA1ICAgICAgZ2V0IC0gMzQ4OQ0KLS0NCmJhc2gkIGphdmEgY29t L2RhbmdhL01lbUNhY2hlZC90ZXN0L01lbUNhY2hlZFRocmVhZEJlbmNoIDUwMDAwIDAgMTEyMTEg MTANClRocmVhZCAgc3RhcnQgICBydW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZShtcykN Ck1haW4gICAgICAgICAgICA1MDAwMDAgIDEyNDg2NSAgICAgICAgICAxNDMwODINCiAgICAgICAg UmVxUGVyU2Vjb25kICAgIHNldCAtIDQwMDQgICAgICBnZXQgLSAzNDk0DQogICAgICAgIA0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0Kc3BjYWNoZWQNCiAgUElEIFVTRVIgICAgIFBSSSAgTkkgIFNJ WkUgIFJTUyBTSEFSRSBTVEFUICVDUFUgJU1FTSAgIFRJTUUgQ09NTUFORA0KMjQ1MzYgeHh4ICAg ICAgIDE1ICAgMCA3NDk0OCAgNzNNICAgNjA4IFMgICAgIDAuMCA1OS4yICAyNTozMSBzcGNhY2hl ZA0KDQpiYXNoJCBqYXZhIGNvbS9kYW5nYS9NZW1DYWNoZWQvdGVzdC9NZW1DYWNoZWRUaHJlYWRC ZW5jaCA1MDAwMDAgMCAxMTIxNiAxDQpUaHJlYWQgIHN0YXJ0ICAgcnVucyAgICBzZXQgdGltZSht cykgICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAgICAgNTAwMDAwICAxOTUxMzYgICAgICAg ICAgMjA5MDk4DQogICAgICAgIFJlcVBlclNlY29uZCAgICBzZXQgLSAyNTYyICAgICAgZ2V0IC0g MjM5MQ0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01lbUNhY2hlZC90ZXN0L01lbUNhY2hlZFRo cmVhZEJlbmNoIDI1MDAwMCAwIDExMjE2IDINClRocmVhZCAgc3RhcnQgICBydW5zICAgIHNldCB0 aW1lKG1zKSAgICBnZXQgdGltZShtcykNCk1haW4gICAgICAgICAgICA1MDAwMDAgIDE5OTgyMCAg ICAgICAgICAyMTM1ODENCiAgICAgICAgUmVxUGVyU2Vjb25kICAgIHNldCAtIDI1MDIgICAgICBn ZXQgLSAyMzQxDQotLQ0KYmFzaCQgamF2YSBjb20vZGFuZ2EvTWVtQ2FjaGVkL3Rlc3QvTWVtQ2Fj aGVkVGhyZWFkQmVuY2ggMTY2NjY2IDAgMTEyMTYgMw0KVGhyZWFkICBzdGFydCAgIHJ1bnMgICAg c2V0IHRpbWUobXMpICAgIGdldCB0aW1lKG1zKQ0KTWFpbiAgICAgICAgICAgIDQ5OTk5OCAgMTkw MTM0ICAgICAgICAgIDIwMzE3MQ0KICAgICAgICBSZXFQZXJTZWNvbmQgICAgc2V0IC0gMjYyOSAg ICAgIGdldCAtIDI0NjANCi0tDQpiYXNoJCBqYXZhIGNvbS9kYW5nYS9NZW1DYWNoZWQvdGVzdC9N ZW1DYWNoZWRUaHJlYWRCZW5jaCAxMjUwMDAgMCAxMTIxNiA0DQpUaHJlYWQgIHN0YXJ0ICAgcnVu cyAgICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAgICAgNTAwMDAw ICAxODkwOTIgICAgICAgICAgMjAyMTY2DQogICAgICAgIFJlcVBlclNlY29uZCAgICBzZXQgLSAy NjQ0ICAgICAgZ2V0IC0gMjQ3Mw0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01lbUNhY2hlZC90 ZXN0L01lbUNhY2hlZFRocmVhZEJlbmNoIDEwMDAwMCAwIDExMjE2IDUNClRocmVhZCAgc3RhcnQg ICBydW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZShtcykNCk1haW4gICAgICAgICAgICA1 MDAwMDAgIDE4OTQ1MiAgICAgICAgICAyMDA4OTMNCiAgICAgICAgUmVxUGVyU2Vjb25kICAgIHNl dCAtIDI2MzkgICAgICBnZXQgLSAyNDg4DQotLQ0KYmFzaCQgamF2YSBjb20vZGFuZ2EvTWVtQ2Fj aGVkL3Rlc3QvTWVtQ2FjaGVkVGhyZWFkQmVuY2ggODMzMzMgMCAxMTIxNiA2DQpUaHJlYWQgIHN0 YXJ0ICAgcnVucyAgICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpNYWluICAgICAgICAg ICAgNDk5OTk4ICAxODg3MDQgICAgICAgICAgMjAxMTAxDQogICAgICAgIFJlcVBlclNlY29uZCAg ICBzZXQgLSAyNjQ5ICAgICAgZ2V0IC0gMjQ4Ng0KLS0NCmJhc2gkIGphdmEgY29tL2RhbmdhL01l bUNhY2hlZC90ZXN0L01lbUNhY2hlZFRocmVhZEJlbmNoIDcxNDI4IDAgMTEyMTYgNw0KVGhyZWFk ICBzdGFydCAgIHJ1bnMgICAgc2V0IHRpbWUobXMpICAgIGdldCB0aW1lKG1zKQ0KTWFpbiAgICAg ICAgICAgIDQ5OTk5NiAgMTg5MjIwICAgICAgICAgIDIwMTM1NA0KICAgICAgICBSZXFQZXJTZWNv bmQgICAgc2V0IC0gMjY0MiAgICAgIGdldCAtIDI0ODMNCi0tDQpiYXNoJCBqYXZhIGNvbS9kYW5n YS9NZW1DYWNoZWQvdGVzdC9NZW1DYWNoZWRUaHJlYWRCZW5jaCA2MjUwMCAwIDExMjE2IDgNClRo cmVhZCAgc3RhcnQgICBydW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZShtcykNCk1haW4g ICAgICAgICAgICA1MDAwMDAgIDE5MDI5MyAgICAgICAgICAyMDE2NjQNCiAgICAgICAgUmVxUGVy U2Vjb25kICAgIHNldCAtIDI2MjcgICAgICBnZXQgLSAyNDc5DQotLQ0KYmFzaCQgamF2YSBjb20v ZGFuZ2EvTWVtQ2FjaGVkL3Rlc3QvTWVtQ2FjaGVkVGhyZWFkQmVuY2ggNTU1NTUgMCAxMTIxNiA5 DQpUaHJlYWQgIHN0YXJ0ICAgcnVucyAgICBzZXQgdGltZShtcykgICAgZ2V0IHRpbWUobXMpDQpN YWluICAgICAgICAgICAgNDk5OTk1ICAxOTExNTIgICAgICAgICAgMjAyMDA0DQogICAgICAgIFJl cVBlclNlY29uZCAgICBzZXQgLSAyNjE1ICAgICAgZ2V0IC0gMjQ3NQ0KLS0NCmJhc2gkIGphdmEg Y29tL2RhbmdhL01lbUNhY2hlZC90ZXN0L01lbUNhY2hlZFRocmVhZEJlbmNoIDUwMDAwIDAgMTEy MTYgMTANClRocmVhZCAgc3RhcnQgICBydW5zICAgIHNldCB0aW1lKG1zKSAgICBnZXQgdGltZSht cykNCk1haW4gICAgICAgICAgICA1MDAwMDAgIDE5MTM1MiAgICAgICAgICAyMDI1NzQNCiAgICAg ICAgUmVxUGVyU2Vjb25kICAgIHNldCAtIDI2MTIgICAgICBnZXQgLSAyNDY4CQ0KDQoNCkJlc3Qg cmVnYXJkc6OsDQoNCmxpdXNpZmFuDQoyMDA3LTA1LTE4DQoNCj4+Pk9uIE1heSAxMSwgMjAwNywg YXQgODo0NiBBTSwgTmllbHMgUHJvdm9zIHdyb3RlOg0KPj4gSSB3b3VsZCByZWFsbHkgbGlrZSB0 byBzZWUgbWVhc3VyZW1lbnRzIG9uIHRoYXQuICAgRG8geW91IGhhdmUgYW55DQo+PiBncmFwaHMg dGhhdCBzaG93IHRoZSBwZXJmb3JtYW5jZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHNpbmdsZS10aHJl YWRlZA0KPj4gYW5kIG11bHRpLXRocmVhZGVkIGltcGxlbWVudGF0aW9uPw0KPg0KPlNwZWFraW5n IG9mIHdoaWNoLCBJJ3ZlIGJlZW4gbWVhbmluZyB0byBiZW5jaG1hcmsgc29tZSBzaW5nbGUtIA0K PnRocmVhZGVkIHZzLiBtdWx0aS10aHJlYWRlZCBsaWJldmVudCBhcHByb2FjaGVzIGZvciBhIHdo aWxlLCBidXQgIA0KPmhhdmVuJ3QgcmVhbGx5IGdvdHRlbiBhcm91bmQgdG8gd29ya2luZyB1cCBh cHByb3ByaWF0ZSBiZW5jaG1hcmsgIA0KPnNvZnR3YXJlLg0KPg0KPkJ1dCBpdCBvY2N1cnMgdG8g bWUuLi55b3UgaGF2ZSB0aG9zZSBuaWNlIGdyYXBocyBvbiB0aGUgbGliZXZlbnQgIA0KPndlYnBh Z2Ugb2YgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4gV2hhdCdkIHlvdSB1c2UgdG8gbWFrZSB0 aGF0PyAgDQo+TWF5YmUgaXQgY291bGQgYmUgYWRhcHRlZCBwcmV0dHkgZWFzaWx5Lg0KPg0KPi0t IA0KPlNjb3R0IExhbWIgPGh0dHA6Ly93d3cuc2xhbWIub3JnLz4NCj4NCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkxpYmV2ZW50LXVzZXJzIG1h aWxpbmcgbGlzdA0KPkxpYmV2ZW50LXVzZXJzQG1vbmtleS5vcmcNCj5odHRwOi8vbW9ua2V5Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xpYmV2ZW50LXVzZXJzDQo+DQo+DQoJCQkNCg0K From nisan.bloch at clickatell.com Tue May 22 07:53:18 2007 From: nisan.bloch at clickatell.com (Nisan Bloch =?ISO-8859-1?B?rSA=?=Clickatell) Date: Tue May 22 08:50:24 2007 Subject: [Libevent-users] Crash in httpd Message-ID: Hi If one is using the http server module in libevent1.3b, sending malformed headers causes a segfault. This is easy to replicate, just telnet to the httpd port and type some junk. Here is a back trace #0 0x0040e43e in evhttp_handle_request (req=0x0, arg=0x82696a8) at http.c:1242 #1 0x0040f011 in evhttp_connection_fail (evcon=0x8268cb0) at http.c:333 #2 0x0040f262 in evhttp_read_header (fd=25, what=2, arg=0x8268cb0) at http.c:949 #3 0x0040af84 in event_base_loop (base=0x8268398, flags=Variable "flags" is not available. ) at event.c:309 #4 0x0040b165 in event_loop (flags=136746664) at event.c:358 #5 0x0040b189 in event_dispatch () at event.c:321 #6 0x080505b6 in ServerMain (pSrvConfig=0x8220400) at ServerMain.c:125 #7 0x0804eeba in main (argc=1, argv=0xbffffaa4) at main.c:286 (gdb) I am not sure whether this should be patched in evhttp_handle_request or evhttp_connection_fail . Thanks Nisan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070522/dc51f349/attachment.htm From elliotf-libevent at gratuitous.net Tue May 22 13:25:33 2007 From: elliotf-libevent at gratuitous.net (Elliot F) Date: Tue May 22 13:25:42 2007 Subject: [Libevent-users] Crash in httpd In-Reply-To: References: Message-ID: <4653278D.70108@gratuitous.net> Nisan Bloch ? Clickatell wrote: > Hi > > If one is using the http server module in libevent1.3b, sending malformed > headers causes a segfault. > This is easy to replicate, just telnet to the httpd port and type some junk. > > Here is a back trace > #0 0x0040e43e in evhttp_handle_request (req=0x0, arg=0x82696a8) at > http.c:1242 > #1 0x0040f011 in evhttp_connection_fail (evcon=0x8268cb0) at http.c:333 > #2 0x0040f262 in evhttp_read_header (fd=25, what=2, arg=0x8268cb0) at > http.c:949 > #3 0x0040af84 in event_base_loop (base=0x8268398, flags=Variable "flags" is > not available. > ) at event.c:309 > #4 0x0040b165 in event_loop (flags=136746664) at event.c:358 > #5 0x0040b189 in event_dispatch () at event.c:321 > #6 0x080505b6 in ServerMain (pSrvConfig=0x8220400) at ServerMain.c:125 > #7 0x0804eeba in main (argc=1, argv=0xbffffaa4) at main.c:286 > (gdb) > > > I am not sure whether this should be patched in evhttp_handle_request or > evhttp_connection_fail . That's odd, because I get a 400 response: $ telnet localhost 1092 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. fasdfsi68&UY^IUYIUYIUY^(*&^*& HTTP/1.1 400 Bad Request Content-Type: text/html Connection: close Content-Length: 134 400 Bad Request

Method Not Implemented

Invalid method in request

Connection closed by foreign host. From kevin.s.ko at gmail.com Tue May 22 14:35:16 2007 From: kevin.s.ko at gmail.com (Kevin Ko) Date: Tue May 22 14:35:21 2007 Subject: [Libevent-users] Crash in httpd In-Reply-To: References: Message-ID: <89aeecfd0705221135o14627a48nc7459108c189cb9a@mail.gmail.com> The line numbers in the back trace correspond to the 1.2 release of libevent. Is there a version number mishap? Kevin On 5/22/07, Nisan Bloch ? Clickatell wrote: > > Hi > > If one is using the http server module in libevent1.3b, sending malformed > headers causes a segfault. > This is easy to replicate, just telnet to the httpd port and type some > junk. > > Here is a back trace > #0 0x0040e43e in evhttp_handle_request (req=0x0, arg=0x82696a8) at > http.c:1242 > #1 0x0040f011 in evhttp_connection_fail (evcon=0x8268cb0) at http.c:333 > #2 0x0040f262 in evhttp_read_header (fd=25, what=2, arg=0x8268cb0) at > http.c:949 > #3 0x0040af84 in event_base_loop (base=0x8268398, flags=Variable "flags" > is not available. > ) at event.c:309 > #4 0x0040b165 in event_loop (flags=136746664) at event.c:358 > #5 0x0040b189 in event_dispatch () at event.c:321 > #6 0x080505b6 in ServerMain (pSrvConfig=0x8220400) at ServerMain.c:125 > #7 0x0804eeba in main (argc=1, argv=0xbffffaa4) at main.c:286 > (gdb) > > > I am not sure whether this should be patched in evhttp_handle_request or > evhttp_connection_fail . > > > > Thanks > > > Nisan > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From jkeller at 454.com Mon May 28 11:28:50 2007 From: jkeller at 454.com (Jesse Keller) Date: Mon May 28 11:28:59 2007 Subject: [Libevent-users] Bug in signal.c Message-ID: <1180366130.18368.8.camel@live> Hello, all -- Just implemented libevent in a new program using the cool eventxx C++ wrapper. Anyway, I decided to track down the event_base_free bug a little more. Here's the original bug and patch. http://monkeymail.org/archives/libevent-users/2006-April/000141.html Seems that we don't need to go through all that effort of fixing the symptom, it's just that the internal event between the signal handler and the dispatcher is never deleted. Here's the patch that fixes the problem for me (versus the 1.3b release) --- signal.c 2007-03-03 23:05:07.000000000 -0500 +++ signal.c.new 2007-05-28 11:10:57.000000000 -0400 @@ -143,6 +143,11 @@ int evsignal; evsignal = EVENT_SIGNAL(ev); + + if (ev_signal_added) { + ev_signal_added = 0; + event_del(&ev_signal); + } return (sigaction(EVENT_SIGNAL(ev),(struct sigaction *)SIG_DFL, NULL)); } -Jesse Keller LEGAL NOTICE: Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. From nickm at freehaven.net Mon May 28 15:11:41 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon May 28 15:11:48 2007 Subject: [Libevent-users] Six patches for evdns.c Message-ID: <20070528191141.GT27410@totoro.wangafu.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070528/bc897730/attachment.bin From slamb at slamb.org Mon May 28 15:37:22 2007 From: slamb at slamb.org (Scott Lamb) Date: Mon May 28 15:37:28 2007 Subject: [Libevent-users] Bug in signal.c In-Reply-To: <1180366130.18368.8.camel@live> References: <1180366130.18368.8.camel@live> Message-ID: <252BA06B-23AE-48A2-B87A-769A9D34F5CF@slamb.org> On May 28, 2007, at 8:28 AM, Jesse Keller wrote: > Just implemented libevent in a new program using the cool eventxx C++ > wrapper. Anyway, I decided to track down the event_base_free bug a > little more. Here's the original bug and patch. > > http://monkeymail.org/archives/libevent-users/2006-April/000141.html > > Seems that we don't need to go through all that effort of fixing the > symptom, it's just that the internal event between the signal handler > and the dispatcher is never deleted. > > Here's the patch that fixes the problem for me (versus the 1.3b > release) > > > --- signal.c 2007-03-03 23:05:07.000000000 -0500 > +++ signal.c.new 2007-05-28 11:10:57.000000000 -0400 > @@ -143,6 +143,11 @@ > int evsignal; > > evsignal = EVENT_SIGNAL(ev); > + > + if (ev_signal_added) { > + ev_signal_added = 0; > + event_del(&ev_signal); > + } > > return (sigaction(EVENT_SIGNAL(ev),(struct sigaction *) > SIG_DFL, > NULL)); > } But ev_signal is for the pipe used to wake up on receipt of *any* signal. Consider this code snippet: signal_set(&ev1, SIGUSR1, signal_cb, NULL); event_add(&ev1, NULL); signal_set(&ev2, SIGUSR2, signal_cb, NULL); event_add(&ev2, NULL); event_del(&ev2); raise(SIGUSR1); event_dispatch(EVLOOP_ONCE); without your change, the dispatch would return immediately. With your change, it would wait until timeout. -- Scott Lamb From provos at citi.umich.edu Mon May 28 17:22:26 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon May 28 17:22:31 2007 Subject: [Libevent-users] Re: Six patches for evdns.c In-Reply-To: <850f7cbe0705281416q6f8cd681g559c412806394b9b@mail.gmail.com> References: <20070528191141.GT27410@totoro.wangafu.net> <850f7cbe0705281416q6f8cd681g559c412806394b9b@mail.gmail.com> Message-ID: <850f7cbe0705281422q45583490h33442a31d0dc14c9@mail.gmail.com> I submitted the rest of the patches to the subversion repository. Thank you again, Niels. On 5/28/07, Niels Provos wrote: > On 5/28/07, Nick Mathewson wrote: > > 02-no-timeout-on-failure.diff > > > > As written, when a nameserver fails quickly, we would set a timeout > > and not actually acknowledge the failure until the timeout had > > elapsed. This isn't necessary, and tended to delay actual retries > > unnecessarily. [I'd appreciate review on this one.] > > We need a test for this one. It looks like the main difference is > that the timeout is no longer added. However, many callers of > evdns_request_transmit seem to ignore the return code. So, it seems > that the whoever made the dns request might never get the callback. > > Niels. > From provos at citi.umich.edu Mon May 28 17:16:15 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon May 28 17:27:06 2007 Subject: [Libevent-users] Re: Six patches for evdns.c In-Reply-To: <20070528191141.GT27410@totoro.wangafu.net> References: <20070528191141.GT27410@totoro.wangafu.net> Message-ID: <850f7cbe0705281416q6f8cd681g559c412806394b9b@mail.gmail.com> On 5/28/07, Nick Mathewson wrote: > 02-no-timeout-on-failure.diff > > As written, when a nameserver fails quickly, we would set a timeout > and not actually acknowledge the failure until the timeout had > elapsed. This isn't necessary, and tended to delay actual retries > unnecessarily. [I'd appreciate review on this one.] We need a test for this one. It looks like the main difference is that the timeout is no longer added. However, many callers of evdns_request_transmit seem to ignore the return code. So, it seems that the whoever made the dns request might never get the callback. Niels. From wouter at NLnetLabs.nl Tue May 29 03:44:35 2007 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Tue May 29 03:44:45 2007 Subject: [Libevent-users] Bug in signal.c In-Reply-To: <252BA06B-23AE-48A2-B87A-769A9D34F5CF@slamb.org> References: <1180366130.18368.8.camel@live> <252BA06B-23AE-48A2-B87A-769A9D34F5CF@slamb.org> Message-ID: <465BD9E3.8090005@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Not sure if 1.3b has my signal patch in it; but I believe I paid attention so that all the internal signal events are deleted properly (on event-base-free). Could be my mistake still, but are you sure that the bug still exists in libevent-trunk? The reason I think its different, is that with my patch (which is in trunk for sure), multiple event bases will use multiple internal events for signal handling where libevent-1.1 would use only one internal event ever. And the bases would clean up their events on free (at least - that is the theory of operation :-) ). Best regards, Wouter Scott Lamb wrote: > > On May 28, 2007, at 8:28 AM, Jesse Keller wrote: > >> Just implemented libevent in a new program using the cool eventxx C++ >> wrapper. Anyway, I decided to track down the event_base_free bug a >> little more. Here's the original bug and patch. >> >> http://monkeymail.org/archives/libevent-users/2006-April/000141.html >> >> Seems that we don't need to go through all that effort of fixing the >> symptom, it's just that the internal event between the signal handler >> and the dispatcher is never deleted. >> >> Here's the patch that fixes the problem for me (versus the 1.3b release) >> >> >> --- signal.c 2007-03-03 23:05:07.000000000 -0500 >> +++ signal.c.new 2007-05-28 11:10:57.000000000 -0400 >> @@ -143,6 +143,11 @@ >> int evsignal; >> >> evsignal = EVENT_SIGNAL(ev); >> + >> + if (ev_signal_added) { >> + ev_signal_added = 0; >> + event_del(&ev_signal); >> + } >> >> return (sigaction(EVENT_SIGNAL(ev),(struct sigaction *)SIG_DFL, >> NULL)); >> } > > But ev_signal is for the pipe used to wake up on receipt of *any* > signal. Consider this code snippet: > > signal_set(&ev1, SIGUSR1, signal_cb, NULL); > event_add(&ev1, NULL); > signal_set(&ev2, SIGUSR2, signal_cb, NULL); > event_add(&ev2, NULL); > event_del(&ev2); > > raise(SIGUSR1); > event_dispatch(EVLOOP_ONCE); > > without your change, the dispatch would return immediately. With your > change, it would wait until timeout. > > --Scott Lamb > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGW9nikDLqNwOhpPgRAkVuAJ93LjcTFeIuEw5jecLf/05LRl0F8QCeIVe2 9DRVVVs8aDY3DzjTBwLepXo= =Gllv -----END PGP SIGNATURE----- From jkeller at 454.com Tue May 29 07:50:20 2007 From: jkeller at 454.com (Jesse Keller) Date: Tue May 29 07:50:26 2007 Subject: [Libevent-users] Bug in signal.c In-Reply-To: <465BD9E3.8090005@nlnetlabs.nl> References: <1180366130.18368.8.camel@live> <252BA06B-23AE-48A2-B87A-769A9D34F5CF@slamb.org> <465BD9E3.8090005@nlnetlabs.nl> Message-ID: <1180439420.5138.7.camel@live> Scott - Quoth Homer: *DOH*. Very true, I only ever had one signal handler. I changed my signal.c to do reference counting so that I can live with myself. Since Wouter fixed it already, though, I'll grab the trunk from subversion and play with that, too. Thanks! -Jesse On Tue, 2007-05-29 at 09:44 +0200, Wouter Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Not sure if 1.3b has my signal patch in it; but I believe I paid > attention so that all the internal signal events are deleted properly > (on event-base-free). Could be my mistake still, but are you sure that > the bug still exists in libevent-trunk? > > The reason I think its different, is that with my patch (which is in > trunk for sure), multiple event bases will use multiple internal events > for signal handling where libevent-1.1 would use only one internal event > ever. And the bases would clean up their events on free (at least - that > is the theory of operation :-) ). > > Best regards, > Wouter > > Scott Lamb wrote: > > > > On May 28, 2007, at 8:28 AM, Jesse Keller wrote: > > > >> Just implemented libevent in a new program using the cool eventxx C++ > >> wrapper. Anyway, I decided to track down the event_base_free bug a > >> little more. Here's the original bug and patch. > >> > >> http://monkeymail.org/archives/libevent-users/2006-April/000141.html > >> > >> Seems that we don't need to go through all that effort of fixing the > >> symptom, it's just that the internal event between the signal handler > >> and the dispatcher is never deleted. > >> > >> Here's the patch that fixes the problem for me (versus the 1.3b release) > >> > >> > >> --- signal.c 2007-03-03 23:05:07.000000000 -0500 > >> +++ signal.c.new 2007-05-28 11:10:57.000000000 -0400 > >> @@ -143,6 +143,11 @@ > >> int evsignal; > >> > >> evsignal = EVENT_SIGNAL(ev); > >> + > >> + if (ev_signal_added) { > >> + ev_signal_added = 0; > >> + event_del(&ev_signal); > >> + } > >> > >> return (sigaction(EVENT_SIGNAL(ev),(struct sigaction *)SIG_DFL, > >> NULL)); > >> } > > > > But ev_signal is for the pipe used to wake up on receipt of *any* > > signal. Consider this code snippet: > > > > signal_set(&ev1, SIGUSR1, signal_cb, NULL); > > event_add(&ev1, NULL); > > signal_set(&ev2, SIGUSR2, signal_cb, NULL); > > event_add(&ev2, NULL); > > event_del(&ev2); > > > > raise(SIGUSR1); > > event_dispatch(EVLOOP_ONCE); > > > > without your change, the dispatch would return immediately. With your > > change, it would wait until timeout. > > > > --Scott Lamb > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkey.org/mailman/listinfo/libevent-users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFGW9nikDLqNwOhpPgRAkVuAJ93LjcTFeIuEw5jecLf/05LRl0F8QCeIVe2 > 9DRVVVs8aDY3DzjTBwLepXo= > =Gllv > -----END PGP SIGNATURE-----