From wouter at NLnetLabs.nl Fri Feb 2 10:51:20 2007 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Fri Feb 2 10:57:05 2007 Subject: [Libevent-users] Linking errors on Solaris 10 Message-ID: <45C35DF8.3050708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Compiling svn trunk on Solaris 10, with gcc gives the following linking errors compiling the samples: Undefined first referenced symbol in file MIN ../.libs/libevent.so inet_aton ../.libs/libevent.so MIN is from http.c, inet_aton is from evdns.c Also from the sample directory, I get many errors: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../compat -c event-test.c In file included from event-test.c:21: ../event.h:301: error: syntax error before "u_int8_t" ../event.h:304: error: syntax error before "u_int32_t" ../event.h:306: error: syntax error before "u_int8_t" ../event.h:309: error: syntax error before "u_int8_t" ../event.h:312: error: syntax error before "u_int8_t" ../event.h:317: error: syntax error before "u_int8_t" ../event.h:319: error: syntax error before "u_int8_t" ../event.h:320: error: syntax error before "u_int32_t" ../event.h:321: error: syntax error before "u_int32_t" ../event.h:324: error: syntax error before "u_int8_t" ../event.h:327: error: syntax error before "u_int8_t" ../event.h:330: error: syntax error before "u_int8_t" ../event.h:333: error: syntax error before "u_int8_t" For many of the sample programs the above errors are printed. checking for u_int64_t... no checking for u_int32_t... no checking for u_int16_t... no checking for u_int8_t... no u_int seems to be used by evtag, and that by evrpc. I could not find any documentation on these exported functions. What do they do? I would like to use libevent on Solaris, because of its devpoll support. Solaris 9 compile results in the same errors. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFw133kDLqNwOhpPgRAktnAKCUVpRv2PYiSHdecLMIGbKdtGM3wgCgpQ7z q8hrv+7F6kgrtcB/XMsaWo8= =n773 -----END PGP SIGNATURE----- From Shanti.Subramanyam at Sun.COM Fri Feb 2 16:31:32 2007 From: Shanti.Subramanyam at Sun.COM (Shanti Subramanyam - PAE) Date: Fri Feb 2 16:31:34 2007 Subject: [Libevent-users] Linking errors on Solaris 10 In-Reply-To: <45C35DF8.3050708@nlnetlabs.nl> References: <45C35DF8.3050708@nlnetlabs.nl> Message-ID: <45C3ADB4.4080903@sun.com> See my earlier post on this in the archives. I'll summarize all the changes required to build on Solaris 10 (and please don't use gcc if you're building on SPARC, use Sun Studio 11) : event.h : Replace all usages of 'u_int*_t' with 'uint*_t'. event_tagging.c, http.c : replace '__inline' with 'inline' event_rpcgen.py: Change 1st line to "#!/usr/bin/env /usr/sfw/bin/python" Run configure as follows : ./configure LDFLAGS="-lnsl -lresolv" If you're using Sun Studio, please set CFLAGS to "-xO4 -xtarget=generic" for good performance. Shanti Wouter Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Compiling svn trunk on Solaris 10, with gcc gives the following linking > errors compiling the samples: > Undefined first referenced > symbol in file > MIN ../.libs/libevent.so > inet_aton ../.libs/libevent.so > MIN is from http.c, inet_aton is from evdns.c > > Also from the sample directory, I get many errors: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../compat -c event-test.c > In file included from event-test.c:21: > ../event.h:301: error: syntax error before "u_int8_t" > ../event.h:304: error: syntax error before "u_int32_t" > ../event.h:306: error: syntax error before "u_int8_t" > ../event.h:309: error: syntax error before "u_int8_t" > ../event.h:312: error: syntax error before "u_int8_t" > ../event.h:317: error: syntax error before "u_int8_t" > ../event.h:319: error: syntax error before "u_int8_t" > ../event.h:320: error: syntax error before "u_int32_t" > ../event.h:321: error: syntax error before "u_int32_t" > ../event.h:324: error: syntax error before "u_int8_t" > ../event.h:327: error: syntax error before "u_int8_t" > ../event.h:330: error: syntax error before "u_int8_t" > ../event.h:333: error: syntax error before "u_int8_t" > For many of the sample programs the above errors are printed. > checking for u_int64_t... no > checking for u_int32_t... no > checking for u_int16_t... no > checking for u_int8_t... no > > u_int seems to be used by evtag, and that by evrpc. I could not find any > documentation on these exported functions. What do they do? > > I would like to use libevent on Solaris, because of its devpoll support. > Solaris 9 compile results in the same errors. > > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFFw133kDLqNwOhpPgRAktnAKCUVpRv2PYiSHdecLMIGbKdtGM3wgCgpQ7z > q8hrv+7F6kgrtcB/XMsaWo8= > =n773 > -----END PGP SIGNATURE----- > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From wouter at NLnetLabs.nl Mon Feb 5 12:03:06 2007 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Mon Feb 5 12:04:03 2007 Subject: [Libevent-users] patch to dealloc evsignal Message-ID: <45C7634A.7090204@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When ev_signal is used, the assertion on line 220 fails on event_base_free(). This is because the signal stuff is not dealloced. Two solutions: remove that assertion (since the event that is not removed is static in signal.c, there is no memory leak here) or use the patch I have attached. The patch I attached also closes the pipe that evsignal_init opened. Hmm, ev_signal does not look at which event_base is used. Is that threadsafe? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFx2NJkDLqNwOhpPgRAqM/AJ4hUuJAkaR5lcSXrl5jXRUQ12y0uQCfXpX3 f11V0I0NasvuBD4ti0x+DiI= =wofl -----END PGP SIGNATURE----- -------------- next part -------------- Index: poll.c =================================================================== --- poll.c (revision 319) +++ poll.c (working copy) @@ -383,6 +383,7 @@ { struct pollop *pop = arg; + evsignal_dealloc(); if (pop->event_set) free(pop->event_set); if (pop->event_r_back) Index: select.c =================================================================== --- select.c (revision 319) +++ select.c (working copy) @@ -358,6 +358,7 @@ { struct selectop *sop = arg; + evsignal_dealloc(); if (sop->event_readset_in) free(sop->event_readset_in); if (sop->event_writeset_in) Index: devpoll.c =================================================================== --- devpoll.c (revision 319) +++ devpoll.c (working copy) @@ -409,6 +409,7 @@ { struct devpollop *devpollop = arg; + evsignal_dealloc(); if (devpollop->fds) free(devpollop->fds); if (devpollop->events) Index: epoll.c =================================================================== --- epoll.c (revision 319) +++ epoll.c (working copy) @@ -357,6 +357,7 @@ { struct epollop *epollop = arg; + evsignal_dealloc(); if (epollop->fds) free(epollop->fds); if (epollop->events) Index: evsignal.h =================================================================== --- evsignal.h (revision 319) +++ evsignal.h (working copy) @@ -33,5 +33,6 @@ int evsignal_deliver(sigset_t *); int evsignal_add(sigset_t *, struct event *); int evsignal_del(sigset_t *, struct event *); +void evsignal_dealloc(void); #endif /* _EVSIGNAL_H_ */ Index: signal.c =================================================================== --- signal.c (revision 319) +++ signal.c (working copy) @@ -47,6 +47,7 @@ #ifdef HAVE_FCNTL_H #include #endif +#include #include "event.h" #include "evsignal.h" @@ -121,10 +122,6 @@ return (0); } -/* - * Nothing to be done here. - */ - int evsignal_del(sigset_t *evsigmask, struct event *ev) { @@ -210,3 +207,14 @@ evsignal_caught = 0; } +void +evsignal_dealloc(void) +{ + if(ev_signal_added) { + event_del(&ev_signal); + ev_signal_added = 0; + } + assert(TAILQ_EMPTY(&signalqueue)); + close(ev_signal_pair[0]); + close(ev_signal_pair[1]); +} Index: event.c =================================================================== --- event.c (revision 319) +++ event.c (working copy) @@ -217,7 +217,6 @@ current_base = NULL; assert(base); - assert(TAILQ_EMPTY(&base->eventqueue)); for (i=0; i < base->nactivequeues; ++i) assert(TAILQ_EMPTY(base->activequeues[i])); @@ -229,6 +228,7 @@ if (base->evsel->dealloc != NULL) base->evsel->dealloc(base->evbase); + assert(TAILQ_EMPTY(&base->eventqueue)); free(base); } From provos at citi.umich.edu Thu Feb 8 11:31:50 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Feb 8 11:31:53 2007 Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS servers to evdns.c (This time with regression tests!) In-Reply-To: <45BF380D.9030307@nlnetlabs.nl> References: <20070129180804.GY22997@totoro.wangafu.net> <45BF380D.9030307@nlnetlabs.nl> Message-ID: <850f7cbe0702080831v158ffa5of3e54456c5330a75@mail.gmail.com> On 1/30/07, Wouter Wijngaards wrote: > Please, why put these really big http and dns protocols into an event > handling library? I would prefer libevent to stay focused on providing > portable select() and alternatives wrappers. > > The http and evdns are pretty big compared to the rest of libevent. They > can be put in their own library(or -ies) perhaps? Some sort of > libevent-driven application support? There has been some talk about libevent creating two different libraries during compile. One would be the traditional libevent and the other one would layer on top of it. Still thinking about the best way of doing this, but you are not the only one with concerns about bloat. Niels. From adam.chou at gmail.com Fri Feb 9 01:13:54 2007 From: adam.chou at gmail.com (Adam Chou) Date: Fri Feb 9 01:14:06 2007 Subject: [Libevent-users] pause libevent? Message-ID: i have a critical section of code where once it starts running, it MUST finish. is there some way to stop libevent so that it doesn't interrupt the execution of my code or do i actually have to event_del() everything then event_add() everything back when i'm done? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070208/44b2676c/attachment.htm From provos at citi.umich.edu Fri Feb 9 02:57:30 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri Feb 9 02:57:34 2007 Subject: [Libevent-users] pause libevent? In-Reply-To: References: Message-ID: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> libevent doesn't do any pre-emptive scheduling. So, I don't understand your problem. Your code can run as long as it likes. It just means that other events don't get handled in the meantime. Niels. On 2/8/07, Adam Chou wrote: > i have a critical section of code where once it starts running, it MUST > finish. is there some way to stop libevent so that it doesn't interrupt the > execution of my code or do i actually have to event_del() everything then > event_add() everything back when i'm done? > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From adam.chou at gmail.com Fri Feb 9 17:05:21 2007 From: adam.chou at gmail.com (Adam Chou) Date: Fri Feb 9 17:05:52 2007 Subject: [Libevent-users] pause libevent? In-Reply-To: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> References: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> Message-ID: sorry, i misunderstood what i was reading, but thanks. with that resolved, i do have a couple of other questions: 1. when using signal_add(), how does the timeout parameter affect the signal handler? i've set it to handle sigalrm and a timeout of 2. if i send the process sigalrm, nothing happens. i wait 2 seconds and nothing happens. but if i set it to 0, then it responds to my sigalrm's that i send it 2. when using struct event to event_set and event_add, am i supposed to use a different struct for each event? i ask because i am setting an event for a fd and one for a signal. when i use the same event for both, i get errors. the errors are also different depending on the timeout value that i pass to the signal handler. if i pass a valid struct timeval to the signal_add, i'll get an abort and the program will dump core. if i pass it a 0 timeout value, i get an error about not being on the queue. sorry if this is something i should know. i'm just not understanding the documentation very well. thanks in advance for your help! On 2/8/07, Niels Provos wrote: > > libevent doesn't do any pre-emptive scheduling. So, I don't > understand your problem. Your code can run as long as it likes. It > just means that other events don't get handled in the meantime. > > Niels. > > On 2/8/07, Adam Chou wrote: > > i have a critical section of code where once it starts running, it MUST > > finish. is there some way to stop libevent so that it doesn't interrupt > the > > execution of my code or do i actually have to event_del() everything > then > > event_add() everything back when i'm done? > > > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkey.org/mailman/listinfo/libevent-users > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070209/7fb40daf/attachment.htm From djm at mindrot.org Fri Feb 9 21:46:21 2007 From: djm at mindrot.org (Damien Miller) Date: Fri Feb 9 21:47:00 2007 Subject: [Libevent-users] pause libevent? In-Reply-To: References: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> Message-ID: On Fri, 9 Feb 2007, Adam Chou wrote: > sorry, i misunderstood what i was reading, but thanks. > > with that resolved, i do have a couple of other questions: > 1. when using signal_add(), how does the timeout parameter affect the signal > handler? i've set it to handle sigalrm and a timeout of 2. if i send the > process sigalrm, nothing happens. i wait 2 seconds and nothing happens. but > if i set it to 0, then it responds to my sigalrm's that i send it works for me. The attached test program produces the expected output: one event after five seconds (SIGALRM) and a timeout event after 10. > 2. when using struct event to event_set and event_add, am i supposed to use > a different struct for each event? Yes. > sorry if this is something i should know. i'm just not understanding the > documentation very well. thanks in advance for your help! If you are in doubt, you might want to look at the libevent code itself (it is very readable) or one of the applications that use it. I'm certainly finding that helpful as I learn it :) -d -------------- next part -------------- #include #include #include #include #include #include void cb(int fd, short ev, void *ctx) { fprintf(stderr, "ping! %d %hd\n", fd, ev); } int main(int argc, char **argv) { struct event ev; struct timeval tv; event_init(); signal_set(&ev, SIGALRM, cb, NULL); tv.tv_sec = 10; tv.tv_usec = 0; signal_add(&ev, &tv); alarm(5); event_dispatch(); fprintf(stderr, "done\n"); return 0; } From personlin118 at yahoo.com.tw Sat Feb 10 12:29:03 2007 From: personlin118 at yahoo.com.tw (Person) Date: Sat Feb 10 12:35:53 2007 Subject: [Libevent-users] event_queue_remove spent too much time In-Reply-To: Message-ID: <320460.64906.qm@web72214.mail.tp2.yahoo.com> Hi, Is it normally that high cost function call issue about event_queue_remove()? I profiles my program with gprof. I found the most spent time function call is event_queue_remove(). However, I only remove events when connection is closed (conn_drop()). There are two types events with flag EV_WRITE and (EV_READ | EV_PERSIST) in my program. And, there are about 250 connections and 250*2 events (read and write fd). ======================================================== [Pseudo Code] static void conn_drop(struct conn *c) { event_del(&c->read_event); event_del(&c->write_event); ... } static void conn_read(int fd, short what, void *d) { struct conn *c = (struct conn*) d; if( read successfully ) { //do something if( we need reply in this time ) event_add(&c->write_event, NULL); } else conn_drop(); } static void conn_write(int fd, short what, void *d) { struct conn *c = (struct conn*) d; if( write successfully ) { //do something } else conn_drop(); // never occur in this test if( write was not completed) event_add(&c->write_event, NULL); // reschedle } void accept_connection() { ... struct conn *c = new (struct conn); event_set(&c->read_event, c->fd, EV_READ | EV_PERSIST, conn_read, c); event_add(&c->read_event, NULL); event_set(&c->write_event, c->fd, EV_WRITE, conn_write, c); } ======================================================== [ result of gprof are listed below] Each sample counts as 0.01 seconds. (no list all!) % cumulative self self total time seconds seconds calls s/call s/call name 8.65 0.34 0.34 85441 0.00 0.00 event_queue_remove (No.1) 5.85 0.57 0.23 GetResource() (No.2) 3.05 1.91 0.12 1225 0.00 0.00 epoll_dispatch 1.40 2.62 0.06 30608 0.00 0.00 conn_write(int, short, void*) 1.02 2.89 0.04 23800 0.00 0.00 conn_read(int, short, void*) 0.89 3.04 0.04 85732 0.00 0.00 event_queue_insert 0.64 3.36 0.03 58045 0.00 0.00 event_add 0.25 3.73 0.01 76 0.00 0.00 conn_drop(connection*, char const*) 0.25 3.76 0.01 1 0.01 2.00 event_base_loop 0.00 3.93 0.00 30771 0.00 0.00 event_del 0.00 3.93 0.00 328 0.00 0.00 server_accept(int, short, void*) ======================================================== Call graph (explanation follows) granularity: each sample hit covers 2 byte(s) for 0.25% of 3.93 seconds index % time self children called name ----------------------------------------------- 0.01 1.99 1/1 event_loop [3] [4] 50.8 0.01 1.99 1 event_base_loop [4] 0.04 1.37 23800/23800 conn_read(int, short, void*) [5] 0.12 0.15 1225/1225 epoll_dispatch [14] 0.22 0.00 54756/85441 event_queue_remove [13] 0.06 0.00 30608/30608 conn_write(int, short, void*) [37] 0.00 0.00 10/30771 event_del [24] 0.00 0.00 10/85732 event_queue_insert [46] 0.00 0.00 1225/2450 evsignal_recalc [160] 0.00 0.00 3675/3687 gettime [170] 0.00 0.00 2450/2450 event_tree_RB_MINMAX [171] 0.00 0.00 1225/1225 epoll_recalc [172] 0.00 0.00 10/10 event_tree_RB_NEXT [177] 0.00 0.00 10/10 event_tree_RB_REMOVE [178] 0.00 0.00 10/54780 event_active [169] ----------------------------------------------- 0.12 0.00 30685/85441 event_del [24] 0.22 0.00 54756/85441 event_base_loop [4] [13] 8.7 0.34 0.00 85441 event_queue_remove [13] ----------------------------------------------- 0.00 0.00 10/30771 event_base_loop [4] 0.00 0.00 152/30771 conn_drop(connection*, char const*) [77] 0.00 0.13 30609/30771 epoll_dispatch [14] [24] 3.4 0.00 0.13 30771 event_del [24] 0.12 0.00 30685/85441 event_queue_remove [13] 0.01 0.00 30685/30685 epoll_del [83] ----------------------------------------------- ___________________________________________________ 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070211/c6598f91/attachment-0001.htm From slamb at slamb.org Sat Feb 10 19:57:48 2007 From: slamb at slamb.org (Scott Lamb) Date: Sat Feb 10 19:58:19 2007 Subject: [Libevent-users] event_queue_remove spent too much time In-Reply-To: <320460.64906.qm@web72214.mail.tp2.yahoo.com> References: <320460.64906.qm@web72214.mail.tp2.yahoo.com> Message-ID: <5C0F478E-7AEE-41C0-B9E2-FA9FC1832285@slamb.org> On Feb 10, 2007, at 9:29 AM, Person wrote: > Hi, > Is it normally that high cost function call issue about > event_queue_remove()? > I profiles my program with gprof. I found the most spent time > function call is event_queue_remove(). > However, I only remove events when connection is closed (conn_drop()). > There are two types events with flag EV_WRITE and (EV_READ | > EV_PERSIST) in my program. And, there are about 250 connections and > 250*2 events (read and write fd). Well, event_queue_remove() is getting called in three different ways. From least to most often, * Twice from each conn_drop(), on the EVLIST_INSERTED queue. * Once implicitly on each write callback on the EVLIST_INSERTED queue, since you're not using EV_PERSIST on writes * Once on each callback on the EVLIST_ACTIVE queue. It just removes the event from a doubly-linked list in O(1) time. So even with so many calls, I'm surprised to see that 8.65%. A few thoughts: * If this trivial function is so high up on the CPU usage, is your program not CPU-bound at all? * Does gprof add overhead to each function call? I don't remember how it works, but if it does, this might unfairly penalize quick but often-called functions like event_queue_remove(). Seems like event_queue_insert() should be in the same boat, though...it gets called as often and does a very similar thing. * Maybe event_queue_remove() is getting a disproportionate number of cache misses and waiting for memory access? Does "valgrind -- tool=cachegrind" give this kind of information? Cheers, Scott -- Scott Lamb From sq at sqstudio.ru Tue Feb 13 11:18:36 2007 From: sq at sqstudio.ru (Dmitry Lohansky) Date: Tue Feb 13 11:19:21 2007 Subject: [Libevent-users] zero-copy support In-Reply-To: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> References: <850f7cbe0702082357n60489e10xf0abb774be4b37e3@mail.gmail.com> Message-ID: <1949035884.20070213191836@sqstudio.ru> Hello Niels. What you plan about zero-copy support for evhttp? It would be nice to use zero-copy evhttp + freebsd with zero_copy_sockets. Maybe better use chain of buffers instead of copy/realloc with one buffer, like nginx do? -- W/ best regards, Dmitry From lorenzo.viscanti at gmail.com Thu Feb 15 04:02:28 2007 From: lorenzo.viscanti at gmail.com (Lorenzo Viscanti) Date: Thu Feb 15 04:02:34 2007 Subject: [Libevent-users] compilation & pyevents Message-ID: Hi, I just compiled libevent 1.2a on a linux server. I had no problems with make and make install (it seems to me..), later when I try to compile pyevent here's what it happens: gcc -pthread -shared build/temp.linux-x86_64-2.4/event.o ../libevent-1.2a/log.o ../libevent-1.2a/strlcpy.o ../libevent-1.2a/signal.o ../libevent-1.2a/epoll.o ../libevent-1.2a/evdns.o ../libevent-1.2a/event.o ../libevent-1.2a/http.o ../libevent-1.2a/poll.o ../libevent-1.2a/select.o ../libevent-1.2a/buffer.o ../libevent-1.2a/event_tagging.o ../libevent-1.2a/evbuffer.o -o build/lib.linux-x86_64-2.4/event.so /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: ../libevent-1.2a/log.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../libevent-1.2a/log.o: could not read symbols: Bad value collect2: ld returned 1 exit status I think that something went wrong with the installation of libevent, right? thanks, lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070215/f704371f/attachment.htm From provos at citi.umich.edu Thu Feb 15 11:10:31 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Feb 15 11:10:38 2007 Subject: [Libevent-users] compilation & pyevents In-Reply-To: References: Message-ID: <850f7cbe0702150810m11e200a4wd6747db9fffb87d8@mail.gmail.com> It means that pyevent is not in sync with libevent. I'd suggest that you email the author of pyevent and strongly suggest to him to finally get his act together and integrate with libevent properly. Niels. On 2/15/07, Lorenzo Viscanti wrote: > Hi, > I just compiled libevent 1.2a on a linux server. I had no problems with make > and make install (it seems to me..), later when I try to compile pyevent > here's what it happens: > > gcc -pthread -shared build/temp.linux-x86_64- 2.4/event.o > ../libevent-1.2a/log.o ../libevent-1.2a/strlcpy.o ../libevent-1.2a/signal.o > ../libevent-1.2a/epoll.o ../libevent-1.2a/evdns.o ../libevent-1.2a/event.o > ../libevent-1.2a/http.o ../libevent-1.2a/poll.o ../libevent- 1.2a/select.o > ../libevent-1.2a/buffer.o ../libevent-1.2a/event_tagging.o > ../libevent-1.2a/evbuffer.o -o build/lib.linux-x86_64-2.4/event.so > /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: > ../libevent- 1.2a/log.o: relocation R_X86_64_32 against `a local symbol' can > not be used when making a shared object; recompile with -fPIC > ../libevent-1.2a/log.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > > > I think that something went wrong with the installation of libevent, right? > > thanks, > lorenzo > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From lorenzo.viscanti at gmail.com Thu Feb 15 14:21:58 2007 From: lorenzo.viscanti at gmail.com (Lorenzo Viscanti) Date: Thu Feb 15 14:22:12 2007 Subject: [Libevent-users] compilation & pyevents In-Reply-To: <850f7cbe0702150810m11e200a4wd6747db9fffb87d8@mail.gmail.com> References: <850f7cbe0702150810m11e200a4wd6747db9fffb87d8@mail.gmail.com> Message-ID: I get the same error even if I use libevent1.2 (I'm using libevent1.2 and pyevent0.3 on my test server). May be pyevent is trying to use some files that have not been updated while recompiling libevent1.2? How can I clean up those files (I used make clean)? Thanks for helping me Lorenzo On 2/15/07, Niels Provos wrote: > > It means that pyevent is not in sync with libevent. I'd suggest that > you email the author of pyevent and strongly suggest to him to finally > get his act together and integrate with libevent properly. > > Niels. > > On 2/15/07, Lorenzo Viscanti wrote: > > Hi, > > I just compiled libevent 1.2a on a linux server. I had no problems with > make > > and make install (it seems to me..), later when I try to compile pyevent > > here's what it happens: > > > > gcc -pthread -shared build/temp.linux-x86_64- 2.4/event.o > > ../libevent-1.2a/log.o ../libevent-1.2a/strlcpy.o ../libevent-1.2a > /signal.o > > ../libevent-1.2a/epoll.o ../libevent-1.2a/evdns.o ../libevent-1.2a > /event.o > > ../libevent-1.2a/http.o ../libevent-1.2a/poll.o ../libevent- 1.2a > /select.o > > ../libevent-1.2a/buffer.o ../libevent-1.2a/event_tagging.o > > ../libevent-1.2a/evbuffer.o -o build/lib.linux-x86_64-2.4/event.so > > > /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: > > ../libevent- 1.2a/log.o: relocation R_X86_64_32 against `a local symbol' > can > > not be used when making a shared object; recompile with -fPIC > > ../libevent-1.2a/log.o: could not read symbols: Bad value > > collect2: ld returned 1 exit status > > > > > > I think that something went wrong with the installation of libevent, > right? > > > > thanks, > > lorenzo > > > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkey.org/mailman/listinfo/libevent-users > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070215/4b8e4295/attachment.htm From provos at citi.umich.edu Thu Feb 15 20:30:01 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Feb 15 20:30:16 2007 Subject: [Libevent-users] libevent-1.3 released Message-ID: <850f7cbe0702151730n64dbf014j8c8f29cefde854c4@mail.gmail.com> Hi everyone, I just released libevent-1.3. It contains a ton of changes: - DNS server from Nick Mathewson - DNS IPv6 from Nick Mathewson - HTTP/1.1 chunked transfer encoding from Dug Song - a ton of other small changes Let me know how it works for you. Niels. From nickm at freehaven.net Fri Feb 16 18:24:34 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Fri Feb 16 18:24:42 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h Message-ID: <20070216232434.GE2505@totoro.wangafu.net> Hi, all! Now that Libevent 1.3 is out, it's time for Patches Less Obvious. One longstanding problems has been that it's not possible to include event.h unless you first define u_int8_t, u_int32_t, struct timeval, and so on. It wasn't possible for event.h to do so itself, since the info needed to decide whether to define those existed only in the config.h file created by autoconf. Here is a patch that solves this problem by renaming "config.h" to "evconfig.h", making it get included from "event.h", and installing it as a header file to $PREFIX/include. This way, people on platforms like mingw and Solaris will be able to build projects that use mingw correctly. This isn't a new or controversial approach, so far as I can tell: many other projects, like mysql, postgresql, glib, expat, firefox, SDL, python, and so on, do the same thing. (For an approximate list, run "ls /usr/include/*/*config.h" on your favorite _nix machine.) The patch is here: http://www.wangafu.net/~nickm/libevent_evconfig_patch/evconfig.diff In addition to this patch, you'll need to rename WIN32-Code/config.h to WIN32-Code/evconfig.h. You'll need to re-run aclocal, autoheader, autoconf, and automake after applying this patch. I have not tested it on all platforms. yrs, -- Nick Mathewson -------------- 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/20070216/32984cc2/attachment.bin From nickm at freehaven.net Fri Feb 16 18:28:52 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Fri Feb 16 18:28:56 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070216232434.GE2505@totoro.wangafu.net> References: <20070216232434.GE2505@totoro.wangafu.net> Message-ID: <20070216232852.GF2505@totoro.wangafu.net> On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote: [...] > This way, people on platforms > like mingw and Solaris will be able to build projects that use mingw > correctly. Oh dear. This is why I should proofread everything _three_ times, I guess. This sentence should read "...to build projects that use event.h correctly." yrs, -- Nick Mathewson -------------- 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/20070216/ff99b764/attachment-0001.bin From nickm at freehaven.net Fri Feb 16 18:45:49 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Fri Feb 16 18:46:03 2007 Subject: [Libevent-users] libevent-1.3 released In-Reply-To: <850f7cbe0702151730n64dbf014j8c8f29cefde854c4@mail.gmail.com> References: <850f7cbe0702151730n64dbf014j8c8f29cefde854c4@mail.gmail.com> Message-ID: <20070216234549.GA14004@totoro.wangafu.net> On Thu, Feb 15, 2007 at 05:30:01PM -0800, Niels Provos wrote: > Hi everyone, > > I just released libevent-1.3. It contains a ton of changes: > > - DNS server from Nick Mathewson Actually, the original DNS server code is by Adam Langley; I only cleaned it up a little. Adam definitely deserves the credit. yrs, -- Nick Mathewson -------------- 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/20070216/49a4f54b/attachment.bin From william at 25thandClement.com Fri Feb 16 19:10:03 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Feb 16 19:10:07 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070216232434.GE2505@totoro.wangafu.net> References: <20070216232434.GE2505@totoro.wangafu.net> Message-ID: <20070217001003.GA29555@wilbur.25thandClement.com> On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote: > Hi, all! > > Now that Libevent 1.3 is out, it's time for Patches Less Obvious. > > One longstanding problems has been that it's not possible to include > event.h unless you first define u_int8_t, u_int32_t, struct timeval, > and so on. It wasn't possible for event.h to do so itself, since the > info needed to decide whether to define those existed only in the > config.h file created by autoconf. > > Here is a patch that solves this problem by renaming "config.h" to > "evconfig.h", making it get included from "event.h", and installing it > as a header file to $PREFIX/include. This way, people on platforms > like mingw and Solaris will be able to build projects that use mingw > correctly. Wouldn't it be cleaner to either 1) Use (unsigned char) instead of (u_int8_t), (unsigned int) instead of (u_int32_t), and include or , conditional on the WIN32 macro; or, if the above isn't portable enough from a theoretical perspective, 2) Build an event.h using M4 and the autotools framework? The additional header just litters things unneccesarily, especially for something this trivial (not to say the headaches are trivial; I build on all these platforms, too). From nickm at freehaven.net Fri Feb 16 19:17:17 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Fri Feb 16 19:17:55 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070217001003.GA29555@wilbur.25thandClement.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> Message-ID: <20070217001717.GH2505@totoro.wangafu.net> On Fri, Feb 16, 2007 at 04:10:03PM -0800, William Ahern wrote: > On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote: > > Hi, all! > > > > Now that Libevent 1.3 is out, it's time for Patches Less Obvious. > > > > One longstanding problems has been that it's not possible to include > > event.h unless you first define u_int8_t, u_int32_t, struct timeval, > > and so on. It wasn't possible for event.h to do so itself, since the > > info needed to decide whether to define those existed only in the > > config.h file created by autoconf. > > > > Here is a patch that solves this problem by renaming "config.h" to > > "evconfig.h", making it get included from "event.h", and installing it > > as a header file to $PREFIX/include. This way, people on platforms > > like mingw and Solaris will be able to build projects that use mingw > > correctly. > > Wouldn't it be cleaner to either > > 1) Use (unsigned char) instead of (u_int8_t), (unsigned int) instead of > (u_int32_t), and include or , conditional on the > WIN32 macro; Actually, you'd want to do unsigned long instead of unsigned int; old C only guarantees that int can hold 16 bits. > or, if the above isn't portable enough from a theoretical perspective, > > 2) Build an event.h using M4 and the autotools framework? > > The additional header just litters things unneccesarily, especially for > something this trivial (not to say the headaches are trivial; I build on all > these platforms, too). I think your approach is reasonable too in the medium term; you should probably send a patch to the list too, so yours can win. :) yrs, -- Nick Mathewson -------------- 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/20070216/64d6dcad/attachment.bin From dgotwisner at rosum.com Fri Feb 16 19:28:26 2007 From: dgotwisner at rosum.com (Dave Gotwisner) Date: Fri Feb 16 19:27:46 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070217001003.GA29555@wilbur.25thandClement.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> Message-ID: <45D64C2A.4030608@rosum.com> William Ahern wrote: >On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote: > > >>Hi, all! >> >>Now that Libevent 1.3 is out, it's time for Patches Less Obvious. >> >>One longstanding problems has been that it's not possible to include >>event.h unless you first define u_int8_t, u_int32_t, struct timeval, >>and so on. It wasn't possible for event.h to do so itself, since the >>info needed to decide whether to define those existed only in the >>config.h file created by autoconf. >> >>Here is a patch that solves this problem by renaming "config.h" to >>"evconfig.h", making it get included from "event.h", and installing it >>as a header file to $PREFIX/include. This way, people on platforms >>like mingw and Solaris will be able to build projects that use mingw >>correctly. >> >> > >Wouldn't it be cleaner to either > >1) Use (unsigned char) instead of (u_int8_t), (unsigned int) instead of >(u_int32_t), and include or , conditional on the >WIN32 macro; > > > Actually, you shouldn't use (unsigned int), very unportable. Use (unsigned long) if you must. I personally hate the proliferation of typedefs. I have seen u8, U8, u_int8, uint8, and many others that all express the same thing. (similarly for 16, 32, and 64 bit sizes). In all cases that I have seen (I admit, I haven't looked recently to see how a DEC-10 implements this, with it's 10 bit bytes), but, for almost every modern implementation I have seen (including MIPS64), char is 8 bits, short is 16, long is 32, and long long is 64. Int is unpredictable and non-portable. That said, the only typedefs I can possibly see of interest are wrappers for 8 bit data types, since "char" implies character data not numeric type data. Also, I have only seen 2 platforms in the years that treat char as unsigned rather than signed, without a specifier, and neither of those platforms exist anymore. Just look in linux/types.h, they define u_short, ushort, u_int16_t, and uint26_t. This is in addition to the __u16 defined in asm/types.h. None of these have platform wrappers around them, which implies the base types are VERY portable. Two header files, 5 defines for the same thing. That said, why not just fix the code for "unsigned" or nothing (you shouldn't need to specify everything as "signed"), followed by "char", "short", "long", or "long long". Any programmer that is worth anything would know the sizes these apply to. Note, that this isn't a flame on libevent per se, I take issue with this everywhere (including the companies I have worked at). From william at 25thandClement.com Fri Feb 16 19:34:01 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Feb 16 19:34:04 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <45D64C2A.4030608@rosum.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> Message-ID: <20070217003401.GA21806@wilbur.25thandClement.com> On Fri, Feb 16, 2007 at 04:28:26PM -0800, Dave Gotwisner wrote: > I personally hate the proliferation of typedefs. I concur whole heartedly. > I have seen u8, U8, u_int8, uint8, and many others that all express the > same thing. (similarly for 16, 32, and 64 bit sizes). In all cases that > I have seen (I admit, I haven't looked recently to see how a DEC-10 > implements this, with it's 10 bit bytes), but, for almost every modern > implementation I have seen (including MIPS64), char is 8 bits, short is > 16, long is 32, and long long is 64. Except on all my machines, where long is 64 bits ;) My machines being an Alpha, UltraSparc, and AMD64, running variously OpenBSD or Linux depending on the season. > Note, that this isn't a flame on libevent per se, I take issue with this > everywhere (including the companies I have worked at). In general I like the libevent coding style, w/ the exception of these typedefs. These typedefs in particular are BSD-derived. Yet, all the BSDs I know also support the C99 typedefs (sans-underscore); that part I never understood. (Maybe it was a close call; not sure which came first in OpenBSD, stdint.h or libevent.) From william at 25thandClement.com Fri Feb 16 19:36:31 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Feb 16 19:36:34 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070217001717.GH2505@totoro.wangafu.net> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <20070217001717.GH2505@totoro.wangafu.net> Message-ID: <20070217003631.GB21806@wilbur.25thandClement.com> On Fri, Feb 16, 2007 at 07:17:17PM -0500, Nick Mathewson wrote: > I think your approach is reasonable too in the medium term; you should > probably send a patch to the list too, so yours can win. :) > *yawn* I'd rather complain from the sidelines whilst other people do the work ;) If I can keep a strong stomach tonight I might dive into the autoconf morass. From sgrimm at facebook.com Fri Feb 16 19:40:28 2007 From: sgrimm at facebook.com (Steven Grimm) Date: Fri Feb 16 19:40:33 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <45D64C2A.4030608@rosum.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> Message-ID: <45D64EFC.6090100@facebook.com> Dave Gotwisner wrote: > I personally hate the proliferation of typedefs. I have seen u8, U8, > u_int8, uint8, and many others that all express the same thing. > (similarly for 16, 32, and 64 bit sizes). The lack of a common standard is the problem, IMO, not the existence of typedefs per se. The underlying problem is that C doesn't provide any built-in portable way of saying you want a data type exactly THIS big, short of resorting to structs with bit-counted fields. None of the built-in types are required to be a particular size, even if they happen to have settled down on particular sizes on present-day architectures. I would much rather waste one line of header file somewhere doing a seemingly redundant typedef than have my code break on some future 128-bit machine whose "long" is 64 bits and "long long" is 128. (Heck, forget "future" -- such machines exist today!) That would be perfectly legal for a C compiler to do. "uint32_t" is much more precise and unambiguous than "unsigned long" -- I read that and have no doubt how big the author expected the data type to be. -Steve From dgotwisner at rosum.com Fri Feb 16 19:58:53 2007 From: dgotwisner at rosum.com (Dave Gotwisner) Date: Fri Feb 16 19:58:14 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <45D64EFC.6090100@facebook.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> <45D64EFC.6090100@facebook.com> Message-ID: <45D6534D.7060802@rosum.com> Steven Grimm wrote: > Dave Gotwisner wrote: > >> I personally hate the proliferation of typedefs. I have seen u8, U8, >> u_int8, uint8, and many others that all express the same thing. >> (similarly for 16, 32, and 64 bit sizes). > > > The lack of a common standard is the problem, IMO, not the existence > of typedefs per se. The underlying problem is that C doesn't provide > any built-in portable way of saying you want a data type exactly THIS > big, short of resorting to structs with bit-counted fields. None of > the built-in types are required to be a particular size, even if they > happen to have settled down on particular sizes on present-day > architectures. I would much rather waste one line of header file > somewhere doing a seemingly redundant typedef than have my code break > on some future 128-bit machine whose "long" is 64 bits and "long long" > is 128. (Heck, forget "future" -- such machines exist today!) That > would be perfectly legal for a C compiler to do. "uint32_t" is much > more precise and unambiguous than "unsigned long" -- I read that and > have no doubt how big the author expected the data type to be. > > -Steve > > Yes, C doesn't define it (ANSI should have at the char/short/long/long long level). Even though there is nothing requiring that short is 16 and long is 32, the fact that the type.h files I mentioned in my previous post imply that they really are required to be these sizes, or the header files be broke. If there were an architecture with char being 8, short being 32, long being 64, and long long being 128 (the National 32032 did this without the long long), there would be no way to express a 16 bit data type, so you couldn't even define an uint16_t type! How would autoconf work in this case? How would you build a types.h for C (not C++) to deal with a 16 bit data type as a native type? How badly would all the code on the planet that uses a uint16_t type work (assuming you can get it to compile)? Note, this is because of the limitation on the C standard, not on the games played by the typedefs. Using your example, if you had a 8, 16, 64, and 128 bit native types, and you wanted an EXACTLY 32 bit type, how would it work? Given ANSI only specifies char, short, long, and long long, when we support 256 bit native types, and you still need the smaller ones (or everything written to date will break), how would you get the fifth type? I have worked on projects where different people are familiar with different type conventions, so the code is written with two or more of the various typedefs, based upon who touches the code when. Note that this is for commercial products not open source, with formal review processes, etc. From sgrimm at facebook.com Fri Feb 16 20:08:03 2007 From: sgrimm at facebook.com (Steven Grimm) Date: Fri Feb 16 20:08:05 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <45D6534D.7060802@rosum.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> <45D64EFC.6090100@facebook.com> <45D6534D.7060802@rosum.com> Message-ID: <45D65573.3030503@facebook.com> Dave Gotwisner wrote: > Using your example, if you had a 8, 16, 64, and 128 bit native types, > and you wanted an EXACTLY 32 bit type, how would it work? Given ANSI > only specifies char, short, long, and long long, when we support 256 > bit native types, and you still need the smaller ones (or everything > written to date will break), how would you get the fifth type? You wouldn't, and your application would fail to build because it's not compatible with that architecture -- which IMO is a better situation than it building just fine (because you used "long") and failing at runtime because the code expected a particular length and got something different. If the failure is in an infrequently-used part of the code you might not discover it until pretty far down the road. Using typedefs gives you fail-fast behavior on systems that can't support the required types. > I have worked on projects where different people are familiar with > different type conventions, so the code is written with two or more of > the various typedefs, based upon who touches the code when. Note that > this is for commercial products not open source, with formal review > processes, etc. Me too, and I'm not defending that practice! If anyone sees redundancy like that in libevent, it should be stamped out immediately. But the fact that word-length typedefs can be used poorly isn't a reason to not use them at all; they do serve a useful purpose in some cases. -Steve From william at 25thandClement.com Fri Feb 16 20:14:04 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Feb 16 20:14:14 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <45D6534D.7060802@rosum.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> <45D64EFC.6090100@facebook.com> <45D6534D.7060802@rosum.com> Message-ID: <20070217011404.GA25229@wilbur.25thandClement.com> On Fri, Feb 16, 2007 at 04:58:53PM -0800, Dave Gotwisner wrote: > Yes, C doesn't define it (ANSI should have at the char/short/long/long > long level). Even though there is nothing requiring that short is 16 > and long is 32, the fact that the type.h files I mentioned in my > previous post imply that they really are required to be these sizes, or > the header files be broke. But C *does* define fixed-width types, through stdint.h, ever since C99 (going on 8 years, now!). And all modern platforms which even contemplate some POSIX/SUSv3 support, provide stdint.h, now, w/ the glaring exception of Microsoft and the Visual Studio suite. Actually, I think that SUSv3 mandates uint8_t, uint16_t, uint32_t, similar to how POSIX/SUS mandates that CHAR_BIT is 8. C99, strictly speaking, only requires the fixed-width types be defined through stdint.h if they can be represented as such. C99 also defines least and fast types. In any event, it kills me that Microsoft won't even add stdint.h. Kills me! People rail against C99 all the time, but the fact is that some very important parts are very nearly universally supported, now, at least in terms of number of distinct enviornments. stdint.h and snprintf() are the two most widely known. From dgotwisner at rosum.com Fri Feb 16 20:31:40 2007 From: dgotwisner at rosum.com (Dave Gotwisner) Date: Fri Feb 16 20:31:00 2007 Subject: [Libevent-users] [Patch] Install autoconf header file as evconfig.h In-Reply-To: <20070217011404.GA25229@wilbur.25thandClement.com> References: <20070216232434.GE2505@totoro.wangafu.net> <20070217001003.GA29555@wilbur.25thandClement.com> <45D64C2A.4030608@rosum.com> <45D64EFC.6090100@facebook.com> <45D6534D.7060802@rosum.com> <20070217011404.GA25229@wilbur.25thandClement.com> Message-ID: <45D65AFC.7030601@rosum.com> William Ahern wrote: >On Fri, Feb 16, 2007 at 04:58:53PM -0800, Dave Gotwisner wrote: > > >>Yes, C doesn't define it (ANSI should have at the char/short/long/long >>long level). Even though there is nothing requiring that short is 16 >>and long is 32, the fact that the type.h files I mentioned in my >>previous post imply that they really are required to be these sizes, or >>the header files be broke. >> >> > >But C *does* define fixed-width types, through stdint.h, ever since C99 >(going on 8 years, now!). And all modern platforms which even contemplate >some POSIX/SUSv3 support, provide stdint.h, now, w/ the glaring exception of >Microsoft and the Visual Studio suite. > >Actually, I think that SUSv3 mandates uint8_t, uint16_t, uint32_t, similar >to how POSIX/SUS mandates that CHAR_BIT is 8. C99, strictly speaking, only >requires the fixed-width types be defined through stdint.h if they can be >represented as such. C99 also defines least and fast types. In any event, it >kills me that Microsoft won't even add stdint.h. Kills me! > >People rail against C99 all the time, but the fact is that some very >important parts are very nearly universally supported, now, at least in >terms of number of distinct enviornments. stdint.h and snprintf() are the >two most widely known. > > > I didn't anticipate that this would go for this long, but... I agree stdint.h is pretty much a standard. It defines the ones you are mentioning. Libevent uses the u_intX_t types (from types.h). As I said, my complaint is in the massive proliferation of these (in many different flavors). In my opinion, C99 (and ANSI) should have specified it at the compiler level NOT the header level, but, oh well. I would much rather see everything get broken by removing the different types from types.h than give everyone every flavor of everything, and then have companies specify their own standard definitions as well. As for Microsoft not providing stdint.h, there is lots more that they provide or not that forces non-standard implementations (such as their template library for C++). Enough said, lets get back to libevent rather than C. From rfistman at gmail.com Sat Feb 17 05:43:11 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Sat Feb 17 05:43:18 2007 Subject: [Libevent-users] iocp status? Message-ID: <131e28b50702170243n79fd1691ka9270f4b87d8fcbf@mail.gmail.com> How's the IOCP support going? I don't see anything about it on http://monkey.org/~provos/libevent/ -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From toby.douglass at summerblue.net Sat Feb 17 06:52:19 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Sat Feb 17 06:51:35 2007 Subject: [Libevent-users] iocp status? In-Reply-To: <131e28b50702170243n79fd1691ka9270f4b87d8fcbf@mail.gmail.com> References: <131e28b50702170243n79fd1691ka9270f4b87d8fcbf@mail.gmail.com> Message-ID: <45D6EC73.1030203@summerblue.net> Rhythmic Fistman wrote: > How's the IOCP support going? I don't see anything about it on > http://monkey.org/~provos/libevent/ My PC is back up. I reinstalled Windows last weekend. I've just finished installing the platform SDK. I'll be working on it tomorrow. (I lost the PSU, the motherboard, the SCSI card and one of the SCSI disks. Ouch!) From toby.douglass at summerblue.net Sun Feb 18 09:54:03 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Sun Feb 18 09:52:59 2007 Subject: [Libevent-users] IOCP Message-ID: <45D8688B.7060003@summerblue.net> Okay, getting some work done. You'll be amused to know that I've now moved away from the VC build environment (although obviously still using the MS Platform SDK and compilers) and I'm using gnumake and a makefile :-) I found when I learned kernel development that the process of requiring a reboot between tests induced me to take much greater care, and so to have a much firmer comprehension, of the code; to write it correctly, and then run it, rather than to write it and then run it till it seems correct. I suspect (and this is my motive) that moving away from source level debugging will have a similar effect. From nickm at freehaven.net Wed Feb 21 03:44:58 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Wed Feb 21 03:45:15 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask Message-ID: <20070221084458.GY22682@totoro.wangafu.net> Hi, all. There's been a recent exchange on the Tor development list about the intersection of signals with pthreads with libevent. Both posts are (I hope) concise, so I'll link to them here: http://archives.seul.org/or/dev/Feb-2007/msg00028.html http://archives.seul.org/or/dev/Feb-2007/msg00030.html In summary: when pthreads are in use, it's wrong to call sigprocmask(), and right to call its identical cousin, pthread_sigmask(). This isn't just a cosmetic issue; it can cause real bugs with signal delivery. Right now, libevent only calls sigprocmask. It would be good if there were some way to tell libevent, "I'm going to use pthreads; use pthread_sigmask() instead of sigprocmask()." I don't know what that interface should be, but the corresponding code should be pretty simple to write. yrs, -- Nick Mathewson -------------- 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/20070221/28d684ac/attachment.bin From william at 25thandClement.com Wed Feb 21 04:29:27 2007 From: william at 25thandClement.com (William Ahern) Date: Wed Feb 21 04:29:32 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <20070221084458.GY22682@totoro.wangafu.net> References: <20070221084458.GY22682@totoro.wangafu.net> Message-ID: <20070221092927.GA9920@wilbur.25thandClement.com> On Wed, Feb 21, 2007 at 03:44:58AM -0500, Nick Mathewson wrote: > libevent, "I'm going to use pthreads; use pthread_sigmask() instead of > sigprocmask()." I don't know what that interface should be, but the > corresponding code should be pretty simple to write. Probably should be a [global] function pointer, since an autoconf check doesn't address the linking issue. From toby.douglass at summerblue.net Wed Feb 21 07:01:55 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 07:01:59 2007 Subject: [Libevent-users] IOCP writes Message-ID: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> I'm adding support for IOCP writes. I've realised, though, that if you issue a write on a socket which currently has an outstanding reading, when the IOCP completes, you don't immediately know which operation has completed. The obvious answer is to use select() to check the socket when an IOCP completes, but that's very awkward, because of the race conditions, for the other operation could complete in the time between the IOCP complete and select() and you have multiple threads calling GQCS concurrently. Locking would be required, which would be Bad. From toby.douglass at summerblue.net Wed Feb 21 07:42:29 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 07:42:32 2007 Subject: [Libevent-users] IOCP writes In-Reply-To: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> References: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> Message-ID: <43333.82.195.181.130.1172061749.squirrel@webmail.serve.com> > I'm adding support for IOCP writes. > > I've realised, though, that if you issue a write on a socket which > currently has an outstanding reading, when the IOCP completes, you don't > immediately know which operation has completed. Obviously I used the completion key. I didn't see it immediately because I'm already using that for something else, bah, hambug. From toby.douglass at summerblue.net Wed Feb 21 08:29:44 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 08:29:49 2007 Subject: [Libevent-users] IOCP writes In-Reply-To: <43333.82.195.181.130.1172061749.squirrel@webmail.serve.com> References: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> <43333.82.195.181.130.1172061749.squirrel@webmail.serve.com> Message-ID: <48006.82.195.181.130.1172064584.squirrel@webmail.serve.com> >> I'm adding support for IOCP writes. >> >> I've realised, though, that if you issue a write on a socket which >> currently has an outstanding reading, when the IOCP completes, you don't >> immediately know which operation has completed. > > Obviously I used the completion key. Actually, that's wrong. On a related note, did someone say that the event handle in the overlapped structure used by the IO functions (ReadFile, etc) is not actually used? If that's actually untouched, I could use it for my own purposes. The alternative is probably a malloc() per write operation :-/ From toby.douglass at summerblue.net Wed Feb 21 08:32:33 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 08:32:36 2007 Subject: [Libevent-users] IOCP writes In-Reply-To: <48006.82.195.181.130.1172064584.squirrel@webmail.serve.com> References: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> <43333.82.195.181.130.1172061749.squirrel@webmail.serve.com> <48006.82.195.181.130.1172064584.squirrel@webmail.serve.com> Message-ID: <48200.82.195.181.130.1172064753.squirrel@webmail.serve.com> I wrote: > On a related note, did someone say that the event handle in the overlapped > structure used by the IO functions (ReadFile, etc) is not actually used? > > If that's actually untouched, I could use it for my own purposes. The > alternative is probably a malloc() per write operation :-/ As it is, it's easy to support serial writes with IOCP, it's supporting multiple concurrent writes which is awkward for a convenient-to-use API over IOCP - and this I would think is absolutely required for some uses of UDP sockets. From toby.douglass at summerblue.net Wed Feb 21 11:59:14 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 11:59:15 2007 Subject: [Libevent-users] IOCP writes In-Reply-To: <48200.82.195.181.130.1172064753.squirrel@webmail.serve.com> References: <39470.82.195.181.130.1172059315.squirrel@webmail.serve.com> <43333.82.195.181.130.1172061749.squirrel@webmail.serve.com> <48006.82.195.181.130.1172064584.squirrel@webmail.serve.com> <48200.82.195.181.130.1172064753.squirrel@webmail.serve.com> Message-ID: <59627.82.195.181.130.1172077154.squirrel@webmail.serve.com> I wrote: > As it is, it's easy to support serial writes with IOCP, it's supporting > multiple concurrent writes which is awkward for a convenient-to-use API > over IOCP - and this I would think is absolutely required for some uses of > UDP sockets. I've figured out a decent way of doing it, a permutation I've never used before, upon the old trick of passing in your own pointer instead of the one you've supposed to use. From luca at integratech.dyndns.org Wed Feb 21 12:29:12 2007 From: luca at integratech.dyndns.org (Leandro Lucarella) Date: Wed Feb 21 12:29:31 2007 Subject: [Libevent-users] eventxx 0.2 released Message-ID: <45DC8168.4090300@integratech.dyndns.org> eventxx is a simple, direct, one-header inline C++ wrapper for libevent. Yes, it's just one header file, so if you want to use it you can just copy the file to your project and you are set (well, you'll need to link to libevent too ;). It's designed to be as close to use to libevent (without compromising modern C++ programming techniques) and efficient (since all implementation is trivial and inline, theoretically, it imposes no overhead at all) as possible. You can download eventxx 0.2 from: http://www.llucax.com.ar/~luca/eventxx/releases/eventxx-0.2.tar.gz Summary of changes: * Several documentation improvements and fixes. * C-like callbacks now make the void* arg parameter optional (since it uses NULL as default). * Test are now not compiled with EVENT_BASE_FREE_FIX as default. For a more detailed changelog please visit the darcsweb interace[7]. Please visit the eventxx website[1] for the latest documentation. You can always get the current[2] release from the release directory[3] or grab the most up to date sources[4] from the darcs[5] repository. You can also take a look the the darcsweb[6] interface to see the latest changes online[7] or subscribe to its RSS feed[8] to follow the development. I hope you find it useful. PS: Please let me know if you find this announcements off topic. [1] http://www.llucax.com.ar/~luca/eventxx/ [2] http://www.llucax.com.ar/~luca/eventxx/releases/eventxx.tar.gz [3] http://www.llucax.com.ar/~luca/eventxx/releases/ [4] http://www.llucax.com.ar/~luca/repos/eventxx/ [5] http://www.darcs.net/ [6] http://auriga.wearlab.de/~alb/darcsweb/ [7] http://www.llucax.com.ar/~luca/repos/darcsweb/?r=eventxx [8] http://www.llucax.com.ar/~luca/repos/darcsweb/?r=eventxx;a=rss -- Leandro Lucarella Integratech S.A. 4571-5252 From rfistman at gmail.com Wed Feb 21 16:59:35 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Wed Feb 21 17:00:32 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211354x3c2e02c1x279f8262dcc3d034@mail.gmail.com> References: <131e28b50702211354x3c2e02c1x279f8262dcc3d034@mail.gmail.com> Message-ID: <131e28b50702211359y35f2edb4s5e7f102e08707021@mail.gmail.com> > From: "Toby Douglass" > I'm adding support for IOCP writes. > > I've realised, though, that if you issue a write on a socket which > currently has an outstanding reading, when the IOCP completes, you don't > immediately know which operation has completed. You use two different OVERLAPPED structures. The pointers returned by GetQueuedCompletionStatus will be different. > The obvious answer is to use select() to check the socket when an IOCP > completes, but that's very awkward, because of the race conditions, for > the other operation could complete in the time between the IOCP complete > and select() and you have multiple threads calling GQCS concurrently. > Locking would be required, which would be Bad. That's doesn't sound right..., IOCP type progs really shouldn't need select. RF -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From rfistman at gmail.com Wed Feb 21 17:00:15 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Wed Feb 21 17:00:36 2007 Subject: [Libevent-users] Re: IOCP writes Message-ID: <131e28b50702211400t23153f3aj2df31b4ae82011c@mail.gmail.com> > From: "Toby Douglass" > > I'm adding support for IOCP writes. > > > > I've realised, though, that if you issue a write on a socket which > > currently has an outstanding reading, when the IOCP completes, you don't > > immediately know which operation has completed. > > Obviously I used the completion key. > > I didn't see it immediately because I'm already using that for something > else, bah, hambug. I don't think you should be passing the same overlapped structure twice to WSARecv/Send. I'm pretty sure that the overlapped isn't "yours" until GetQueuedCompletionStatus says so. Try a unique overlapped structure for each overlappable call. -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From rfistman at gmail.com Wed Feb 21 18:09:18 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Wed Feb 21 18:09:20 2007 Subject: [Libevent-users] Re: IOCP writes Message-ID: <131e28b50702211509r2567ffdev39633a1115af33e@mail.gmail.com> > From: "Toby Douglass" > >> I've realised, though, that if you issue a write on a socket which > >> currently has an outstanding reading, when the IOCP completes, you don't > >> immediately know which operation has completed. > > > > Obviously I used the completion key. > > Actually, that's wrong. > > On a related note, did someone say that the event handle in the overlapped > structure used by the IO functions (ReadFile, etc) is not actually used? > > If that's actually untouched, I could use it for my own purposes. The > alternative is probably a malloc() per write operation :-/ You shouldn't have to touch that stuff. What are you trying to do? Issuing simultaneous asynchronous reads and writes on socket is a tiny bit rare and special. Are you sure that's what you want to do? If so, great - io completion queues can handle it. Bu-ut if libevent was modelled on the unix select-style interfaces, most of which don't easily support this kind of thing, how is this situation cropping up, assuming that this is just an IOCP port of libevent? The unixy case is trickier - I think only kqueues can handle two separate read/write readiness requests being queued up in separate invocations. With all the other interfaces (epoll, event ports, select) you can request read AND write readiness notification, but you have to do with the one system call (the select interface makes this obvious, the other less so). -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From toby.douglass at summerblue.net Wed Feb 21 18:24:03 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 18:24:07 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211354x3c2e02c1x279f8262dcc3d034@mail.gmail.com> References: <131e28b50702211354x3c2e02c1x279f8262dcc3d034@mail.gmail.com> Message-ID: <45DCD493.1070401@summerblue.net> Rhythmic Fistman wrote: >> From: "Toby Douglass" >> I've realised, though, that if you issue a write on a socket which >> currently has an outstanding reading, when the IOCP completes, you don't >> immediately know which operation has completed. > > You use two different OVERLAPPED structures. The pointers returned > by GetQueuedCompletionStatus will be different. Yup. I'll be passing in a struct which contains that overlapped as its first member. When it comes back to be, I'll cast the overlapped pointer to my struct type. I think this means though I need a malloc per write, since I have to create the overlapped structure. That's bad, since the point of this is high throughput. >> The obvious answer is to use select() to check the socket when an IOCP >> completes, but that's very awkward, because of the race conditions, for >> the other operation could complete in the time between the IOCP complete >> and select() and you have multiple threads calling GQCS concurrently. >> Locking would be required, which would be Bad. > > That's doesn't sound right..., IOCP type progs really shouldn't need > select. Quite right. From toby.douglass at summerblue.net Wed Feb 21 18:25:20 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 18:25:01 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211400t23153f3aj2df31b4ae82011c@mail.gmail.com> References: <131e28b50702211400t23153f3aj2df31b4ae82011c@mail.gmail.com> Message-ID: <45DCD4E0.7070900@summerblue.net> Rhythmic Fistman wrote: > I don't think you should be passing the same overlapped structure > twice to WSARecv/Send. I'm pretty sure that the overlapped isn't > "yours" until GetQueuedCompletionStatus says so. Try a unique > overlapped structure for each overlappable call. Don't worry, I'm not re-using overlapped's like that. I've had just the one overlapped struct till now, because I only did reads, and you only have one read outstanding at a time. From toby.douglass at summerblue.net Wed Feb 21 18:30:25 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 18:29:57 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211509r2567ffdev39633a1115af33e@mail.gmail.com> References: <131e28b50702211509r2567ffdev39633a1115af33e@mail.gmail.com> Message-ID: <45DCD611.7050402@summerblue.net> Rhythmic Fistman wrote: >> From: "Toby Douglass" >> If that's actually untouched, I could use it for my own purposes. The >> alternative is probably a malloc() per write operation :-/ > > You shouldn't have to touch that stuff. What are you trying to do? Keep state on a per read/write basis. Currently I keep state on a per socket basis, but that's not enough to let you know which of an arbitrary number of writes has just completed. However, I'm not going to use the abovementioned rather awful method (which I only considered from lack of alternatives) because I'm going to hijack the OVERLAPPED pointer, which is the right way to do this (or the least wrong way). > Issuing simultaneous asynchronous reads and writes on socket is a tiny bit > rare and special. I agree, but there are so many possible users people are going to want to do it. Also, it's common enough I think - HTTP with keep-alive, you could want to implement that using async IO for both the read and the write on the socket. > Are you sure that's what you want to do? If so, great - > io completion queues can handle it. Bu-ut if libevent was modelled on > the unix > select-style interfaces, most of which don't easily support this kind of > thing, > how is this situation cropping up, assuming that this is just an IOCP port > of libevent? That's a wider question. I'm simply implementing a dead-easy-to-use API on IOCP. > The unixy case is trickier - I think only kqueues can handle two separate > read/write readiness requests being queued up in separate invocations. > With all the other interfaces (epoll, event ports, select) you can > request read AND write readiness notification, but you have to do > with the one system call (the select interface makes this obvious, > the other less so). UNIX, I know nnnnnnnnnnnnnnnnathing. Well, not quite true, I know POSIX somewhat, but true enough here for the better IO mechanisms. From toby.douglass at summerblue.net Wed Feb 21 19:03:48 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Wed Feb 21 19:03:08 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211540p58665599i9410e57e6cb3b756@mail.gmail.com> References: <131e28b50702211354x3c2e02c1x279f8262dcc3d034@mail.gmail.com> <45DCD475.9050708@summerblue.net> <131e28b50702211540p58665599i9410e57e6cb3b756@mail.gmail.com> Message-ID: <45DCDDE4.8050201@summerblue.net> Rhythmic Fistman wrote: > On 2/22/07, Toby Douglass wrote: >> Yup. I'll be passing in a struct which contains that overlapped as its >> first member. When it comes back to be, I'll cast the overlapped >> pointer to my struct type. I think this means though I need a malloc >> per write, since I have to create the overlapped structure. That's bad, >> since the point of this is high throughput. > > I don't think malloc's going to eat that much into your io-bound > code's performance, > but if you're worried about it just reuse the same overlapped structure > instead > of re-mallocing it. I don't want to have to be in a situation where I have to cache my allocations - it's extra code to write and debug and it impacts upon the cleanliness and simplicity of the design. It's a shame, really - with serial async writes, the only malloc you do is up front, once, when the socket is handed over to the API. From william at 25thandClement.com Wed Feb 21 19:15:38 2007 From: william at 25thandClement.com (William Ahern) Date: Wed Feb 21 19:15:42 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702211509r2567ffdev39633a1115af33e@mail.gmail.com> References: <131e28b50702211509r2567ffdev39633a1115af33e@mail.gmail.com> Message-ID: <20070222001538.GA17629@wilbur.25thandClement.com> On Thu, Feb 22, 2007 at 12:09:18AM +0100, Rhythmic Fistman wrote: > Issuing simultaneous asynchronous reads and writes on socket is a tiny bit > rare and special. Are you sure that's what you want to do? If so, great - > io completion queues can handle it. Bu-ut if libevent was modelled on the > unix > select-style interfaces, most of which don't easily support this kind of > thing, > how is this situation cropping up, assuming that this is just an IOCP port > of libevent? Almost all of my use of libevent involves simultaneous reads/writes, for relays which filter streams on-the-fly, in both directions. It was tricky at first, but over the course of several revisions it all settled out. *sigh* Someday I'll have to muster up the energy to change the name, because on this list its just damn confusing, but my buffered-IO implementation is in libevnet: http://www.25thandclement.com/~william/projects/libevnet.html Specifically, see src/bufio/socket.c and the functions bufio_socket_event_run bufio_socket_event_mod bufio_socket_event_del bufio_socket_event_add bufio_socket_poll_handler bufio_sink_poll_handler Cancellations were tricky. Also, what I fail to see in most async libraries is logic to handle re-entrancy from recursive callbacks. That's what the FRAME_PUSH/FRAME_POP calls are all about. evdns.c fails in this respect, last time I looked, as does c-ares; they'll just segfault. My lookup API, built around c-ares, works around the c-ares problem w/ what I consider an abysmal hack; I'm looking to maybe fork the guts into libevnet because my re-entrancy patches were rejected. Anyhow, lookup.c does much, much more than c-ares, ADNS, or evdns, combined. From toby.douglass at summerblue.net Thu Feb 22 08:43:48 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Thu Feb 22 08:43:56 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> Message-ID: <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> > From: "Toby Douglass" >> As it is, it's easy to support serial writes with IOCP, it's supporting >> multiple concurrent writes which is awkward for a convenient-to-use API >> over IOCP - and this I would think is absolutely required for some uses >> of UDP sockets. > I haven't tried any UDP async socket stuff, not with IOCPs nor anything. > Tell us how it goes! Well, it's something I've rarely needed to do - in fact, only for P2P VOIP. However, the example I had in mind (which is similar) is P2P apps, which use writes on a single local UDP socket to send peering information to peers. They would benefit from async writes on that socket. > Still, I think I'm missing the point of multiple > concurrent writes - wouldn't the output be undefined? Ah, no, because the destination on a UDP socket will be specified for each write. For a TCP socket, your concern is correct, multiple async writes would only be useful if each write was independent of every other write, so the ordering of dispatch didn't matter. (We would also need to assume each send() function call wrote its payload atomically with regard to other send() function calls, which I think is true, although I don't know that it is actually guaranteed). From rfistman at gmail.com Thu Feb 22 08:31:52 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Thu Feb 22 08:51:58 2007 Subject: [Libevent-users] Re: IOCP writes Message-ID: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> > From: "Toby Douglass" > > I wrote: > > On a related note, did someone say that the event handle in the overlapped > > structure used by the IO functions (ReadFile, etc) is not actually used? > > > > If that's actually untouched, I could use it for my own purposes. The > > alternative is probably a malloc() per write operation :-/ > > As it is, it's easy to support serial writes with IOCP, it's supporting > multiple concurrent writes which is awkward for a convenient-to-use API > over IOCP - and this I would think is absolutely required for some uses of > UDP sockets. I haven't tried any UDP async socket stuff, not with IOCPs nor anything. Tell us how it goes! Still, I think I'm missing the point of multiple concurrent writes - wouldn't the output be undefined? -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From william at 25thandClement.com Thu Feb 22 14:59:40 2007 From: william at 25thandClement.com (William Ahern) Date: Thu Feb 22 15:01:32 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> Message-ID: <20070222195940.GA8806@wilbur.25thandClement.com> On Thu, Feb 22, 2007 at 01:43:48PM -0000, Toby Douglass wrote: > > From: "Toby Douglass" > >> As it is, it's easy to support serial writes with IOCP, it's supporting > >> multiple concurrent writes which is awkward for a convenient-to-use API > >> over IOCP - and this I would think is absolutely required for some uses > >> of UDP sockets. > > > I haven't tried any UDP async socket stuff, not with IOCPs nor anything. > > Tell us how it goes! > > Well, it's something I've rarely needed to do - in fact, only for P2P VOIP. > > However, the example I had in mind (which is similar) is P2P apps, which > use writes on a single local UDP socket to send peering information to > peers. They would benefit from async writes on that socket. Writing to a UDP socket should never block, period. If the output buffer is full, and you write another message, it should force the stack to drop a message. But, that could just as well have happened on the wire, so what's the difference? Likely what the NIC can push out and what the link can handle is different, so trying to cater to the output buffer is a futile excercise, as far as I can see. > > Still, I think I'm missing the point of multiple > > concurrent writes - wouldn't the output be undefined? > > Ah, no, because the destination on a UDP socket will be specified for each > write. For a TCP socket, your concern is correct, multiple async writes > would only be useful if each write was independent of every other write, > so the ordering of dispatch didn't matter. (We would also need to assume > each send() function call wrote its payload atomically with regard to > other send() function calls, which I think is true, although I don't know > that it is actually guaranteed). It is guaranteed. You may get truncation or fragmentation, but a UDP fragment is still a logical, discrete unit. From toby.douglass at summerblue.net Thu Feb 22 15:26:22 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Thu Feb 22 15:26:57 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <20070222195940.GA8806@wilbur.25thandClement.com> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> <20070222195940.GA8806@wilbur.25thandClement.com> Message-ID: <45DDFC6E.1050202@summerblue.net> William Ahern wrote: > On Thu, Feb 22, 2007 at 01:43:48PM -0000, Toby Douglass wrote: >> However, the example I had in mind (which is similar) is P2P apps, which >> use writes on a single local UDP socket to send peering information to >> peers. They would benefit from async writes on that socket. > > Writing to a UDP socket should never block, period. If the output buffer is > full, and you write another message, it should force the stack to drop a > message. Good point. I'd forgotten about that. > But, that could just as well have happened on the wire, so what's > the difference? It would be more reliable not to fail locally if you could avoid it. The fact it *could* happen on the wire doesn't give us license to drop things when we could have avoided it. > Likely what the NIC can push out and what the link can > handle is different, so trying to cater to the output buffer is a futile > excercise, as far as I can see. So, the final implication is that users will ONLY ever perform serial writes on a socket, no matter what it is? From toby.douglass at summerblue.net Thu Feb 22 16:01:00 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Thu Feb 22 15:59:54 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <45DDFC6E.1050202@summerblue.net> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> <20070222195940.GA8806@wilbur.25thandClement.com> <45DDFC6E.1050202@summerblue.net> Message-ID: <45DE048C.20202@summerblue.net> Toby Douglass wrote: > William Ahern wrote: >> On Thu, Feb 22, 2007 at 01:43:48PM -0000, Toby Douglass wrote: >>> However, the example I had in mind (which is similar) is P2P apps, which >>> use writes on a single local UDP socket to send peering information to >>> peers. They would benefit from async writes on that socket. >> >> Writing to a UDP socket should never block, period. If the output >> buffer is >> full, and you write another message, it should force the stack to drop a >> message. > > Good point. I'd forgotten about that. However, I've just realized that it may make no difference. Writing to a UDP socket should never block; agreed. However, that multiple concurrent writes (one socket, many writer threads) can occur, and so the internal mechanics of the IOCP API must support that behaviour (assume we have enough bandwidth and the write rate is low enough that we're not dropping packets). If I only have a single overlapped structure for writes, I cannot support that behaviour. So I have to malloc the overlapped structure per write (or have the user pass one in). From william at 25thandClement.com Thu Feb 22 17:24:09 2007 From: william at 25thandClement.com (William Ahern) Date: Thu Feb 22 17:24:12 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <45DDFC6E.1050202@summerblue.net> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> <20070222195940.GA8806@wilbur.25thandClement.com> <45DDFC6E.1050202@summerblue.net> Message-ID: <20070222222409.GA3294@wilbur.25thandClement.com> On Thu, Feb 22, 2007 at 08:26:22PM +0000, Toby Douglass wrote: > >Likely what the NIC can push out and what the link can > >handle is different, so trying to cater to the output buffer is a futile > >excercise, as far as I can see. > > So, the final implication is that users will ONLY ever perform serial > writes on a socket, no matter what it is? I'm not following. What I was trying to say is that I suspect the NIC will push packets onto the network faster than the network can handle. Meaning, trying not to overflow the local buffer doesn't buy you anything. Example: If the NIC is on a 100BaseT, but the gateway is on a T3, even if you didn't overflow the UDP stack locally, you'd still get tons of packet loss at the gateway, because it couldn't possibly forward them all onto the T3. In other words, trying to limit your send rate by using the local buffer as a throttle doesn't make sense; the local buffer is almost never the bottleneck, unless you've still got a USR Sportster on a serial cable ;) So, at the end of the day, to send UDP packets all you need to do is call send() or sendto(). No IOCP, no polling, no nothing. Everything goes out as discrete units, so you don't need anything worry about concurrent thread access or anything like that, either. You're socket writes will never get interleaved, since that's simply not the way UDP works at any level (protocol, implementation, or API). From william at 25thandClement.com Thu Feb 22 17:27:57 2007 From: william at 25thandClement.com (William Ahern) Date: Thu Feb 22 17:28:01 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <45DE048C.20202@summerblue.net> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> <20070222195940.GA8806@wilbur.25thandClement.com> <45DDFC6E.1050202@summerblue.net> <45DE048C.20202@summerblue.net> Message-ID: <20070222222757.GB3294@wilbur.25thandClement.com> On Thu, Feb 22, 2007 at 09:01:00PM +0000, Toby Douglass wrote: > However, I've just realized that it may make no difference. > > Writing to a UDP socket should never block; agreed. > > However, that multiple concurrent writes (one socket, many writer > threads) can occur, and so the internal mechanics of the IOCP API must > support that behaviour (assume we have enough bandwidth and the write > rate is low enough that we're not dropping packets). > > If I only have a single overlapped structure for writes, I cannot > support that behaviour. > > So I have to malloc the overlapped structure per write (or have the user > pass one in). I admittedly don't no anything about IOCP. What I do no is that it doesn't make sense to use any other function call then send() or sendto() to write out UDP data. So whatever API your writing around IOCP, it should short-circuit for UDP writes; just call send() to sendto(). But, that's all I'll say for now, since eventually I'm just going to look foolish for my lack of IOCP knowledge. From toby.douglass at summerblue.net Thu Feb 22 18:24:41 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Thu Feb 22 18:24:24 2007 Subject: [Libevent-users] Re: IOCP writes In-Reply-To: <20070222222757.GB3294@wilbur.25thandClement.com> References: <131e28b50702220531n6b781132y94a0c0688fabf780@mail.gmail.com> <41778.82.195.181.130.1172151828.squirrel@webmail.serve.com> <20070222195940.GA8806@wilbur.25thandClement.com> <45DDFC6E.1050202@summerblue.net> <45DE048C.20202@summerblue.net> <20070222222757.GB3294@wilbur.25thandClement.com> Message-ID: <45DE2639.1010406@summerblue.net> William Ahern wrote: > I admittedly don't no anything about IOCP. What I do no is that it doesn't > make sense to use any other function call then send() or sendto() to write > out UDP data. So whatever API your writing around IOCP, it should > short-circuit for UDP writes; just call send() to sendto(). > > But, that's all I'll say for now, since eventually I'm just going to look > foolish for my lack of IOCP knowledge. Well, I think here in lack of knowledge has led you to point out something that I simply hadn't thought of because I've been thinking about everything in terms of IOCP. From slamb at slamb.org Thu Feb 22 20:52:10 2007 From: slamb at slamb.org (Scott Lamb) Date: Thu Feb 22 20:52:19 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <20070221092927.GA9920@wilbur.25thandClement.com> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> Message-ID: <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> On Feb 21, 2007, at 1:29 AM, William Ahern wrote: > On Wed, Feb 21, 2007 at 03:44:58AM -0500, Nick Mathewson wrote: > >> libevent, "I'm going to use pthreads; use pthread_sigmask() >> instead of >> sigprocmask()." I don't know what that interface should be, but the >> corresponding code should be pretty simple to write. > > Probably should be a [global] function pointer, since an autoconf > check > doesn't address the linking issue. What about just never using sigprocmask() or pthread_sigmask()? The patch I sent to the list a while back fixes two bugs: * prevents Anton Povarov's reported race in which a signal delivered quickly after event_signal_add() isn't handled correctly * avoids sigprocmask(), which is not pthread-safe. There are still several caveats with threads. Ignoring the complex idea of sharing an event_base between threads (need still has to be proven...I've been way too busy with other things to run the benchmarks I've been wanting to), these ones remain: 2. If you forget event_base_set on an event, it's associated with the latest base created. This will probably work most of the time. It'd be much less confusing if it consistently broke. 3. Each new base created leaks the existing ev_signal_pair descriptors. 4. Signals are delivered to whatever event loop happens to see them first. 6. You can't destroy an event_base. My old patch and notes are below. This patch does not get rid of ncalls, which I'm also thinking of doing, as I mentioned in an earlier message to the list. devpoll.c | 15 +++-------- epoll.c | 15 +++-------- evport.c | 17 +++---------- evsignal.h | 8 ++---- poll.c | 15 +++-------- select.c | 14 +++------- signal.c | 74 +++++++++++++++ +----------------------------------------- test/regress.c | 32 ++++++++++++++++++++++++ 8 files changed, 76 insertions(+), 114 deletions(-) There's one subtlety to it. With my change, evsignal_process() runs with signals unblocked, so timing is critical. The original code is then racy: TAILQ_FOREACH(ev, &signalqueue, ev_signal_next) { ncalls = evsigcaught[EVENT_SIGNAL(ev)]; <-- point A if (ncalls) { if (!(ev->ev_events & EV_PERSIST)) event_del(ev); event_active(ev, EV_SIGNAL, ncalls); } } memset(evsigcaught, 0, sizeof(evsigcaught)); <-- point B evsignal_caught = 0; <-- point C For any signal that is not already pending (ncalls == 0 when reaching its point A), if it arrives between then and its ncalls being cleared in point B, it will be lost. If it arrives after then but before evsignal_caught in point C, it will be arbitrarily delayed (until another signal comes along to set evsignal_caught). I solved this by * moving the evsignal_caught to before checking the individual signals for delivery (but after evsignal_caught is checked itself, in a different function). * setting "evsigcaught[x] = 0" only when we are setting that signal active. -- Scott Lamb -------------- next part -------------- A non-text attachment was scrubbed... Name: event-signal.patch Type: application/octet-stream Size: 12825 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070222/f82f94b3/event-signal.obj -------------- next part -------------- From provos at citi.umich.edu Thu Feb 22 21:32:23 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Feb 22 21:32:57 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> Message-ID: <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> Do you have an addition to the regression test that would allow me to verify that the new code works as intended? If not, it would be most appreciated :-) Niels. On 2/22/07, Scott Lamb wrote: > > On Feb 21, 2007, at 1:29 AM, William Ahern wrote: > > > On Wed, Feb 21, 2007 at 03:44:58AM -0500, Nick Mathewson wrote: > > > >> libevent, "I'm going to use pthreads; use pthread_sigmask() > >> instead of > >> sigprocmask()." I don't know what that interface should be, but the > >> corresponding code should be pretty simple to write. > > > > Probably should be a [global] function pointer, since an autoconf > > check > > doesn't address the linking issue. > > What about just never using sigprocmask() or pthread_sigmask()? The > patch I sent to the list a while back fixes two bugs: > > * prevents Anton Povarov's reported race in which a signal delivered > quickly after event_signal_add() isn't handled correctly > * avoids sigprocmask(), which is not pthread-safe. > > There are still several caveats with threads. Ignoring the complex > idea of sharing an event_base between threads (need still has to be > proven...I've been way too busy with other things to run the > benchmarks I've been wanting to), these ones remain: > > 2. If you forget event_base_set on an event, it's associated with the > latest base created. This will probably work most of the time. It'd > be much less confusing if it consistently broke. > > 3. Each new base created leaks the existing ev_signal_pair descriptors. > > 4. Signals are delivered to whatever event loop happens to see them > first. > > 6. You can't destroy an event_base. > > My old patch and notes are below. > > This patch does not get rid of ncalls, which I'm also thinking of > doing, as I mentioned in an earlier message to the list. > > devpoll.c | 15 +++-------- > epoll.c | 15 +++-------- > evport.c | 17 +++---------- > evsignal.h | 8 ++---- > poll.c | 15 +++-------- > select.c | 14 +++------- > signal.c | 74 +++++++++++++++ > +----------------------------------------- > test/regress.c | 32 ++++++++++++++++++++++++ > 8 files changed, 76 insertions(+), 114 deletions(-) > > There's one subtlety to it. With my change, evsignal_process() runs > with signals unblocked, so timing is critical. The original code is > then racy: > > TAILQ_FOREACH(ev, &signalqueue, ev_signal_next) { > ncalls = evsigcaught[EVENT_SIGNAL(ev)]; <-- point A > if (ncalls) { > if (!(ev->ev_events & EV_PERSIST)) > event_del(ev); > event_active(ev, EV_SIGNAL, ncalls); > } > } > > memset(evsigcaught, 0, sizeof(evsigcaught)); <-- point B > evsignal_caught = 0; <-- point C > > For any signal that is not already pending (ncalls == 0 when reaching > its point A), if it arrives between then and its ncalls being cleared > in point B, it will be lost. If it arrives after then but before > evsignal_caught in point C, it will be arbitrarily delayed (until > another signal comes along to set evsignal_caught). > > I solved this by > > * moving the evsignal_caught to before checking the individual > signals for delivery (but after evsignal_caught is checked itself, in > a different function). > * setting "evsigcaught[x] = 0" only when we are setting that signal > active. > > -- > Scott Lamb > > > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > From slamb at slamb.org Thu Feb 22 21:37:41 2007 From: slamb at slamb.org (Scott Lamb) Date: Thu Feb 22 21:37:54 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> Message-ID: On Feb 22, 2007, at 6:32 PM, Niels Provos wrote: > Do you have an addition to the regression test that would allow me to > verify that the new code works as intended? If not, it would be most > appreciated :-) There is one that verifies the quickly received signal case. Are you talking about the race condition I describe? In that case, no...I could try something that pounds on it in a loop for a bit or something, if you like. Also realized I sent an older version of the patch just now...newer one attached. (Why can I never send a patch to a mailing list correctly the first time? It's a bizarre handicap.) -------------- next part -------------- A non-text attachment was scrubbed... Name: event-signal.patch Type: application/octet-stream Size: 14204 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070222/daeb3b97/event-signal-0001.obj From nickm at freehaven.net Thu Feb 22 22:15:27 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Thu Feb 22 22:15:48 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> Message-ID: <20070223031527.GL22682@totoro.wangafu.net> On Thu, Feb 22, 2007 at 05:52:10PM -0800, Scott Lamb wrote: [...] > What about just never using sigprocmask() or pthread_sigmask()? The > patch I sent to the list a while back fixes two bugs: > > * prevents Anton Povarov's reported race in which a signal delivered > quickly after event_signal_add() isn't handled correctly > * avoids sigprocmask(), which is not pthread-safe. I like your approach; it seems a lot more elegant than the block-and-unblock approach in the current code. It looks at least superficially okay to me. My only libevent thread needs (for Tor) are to be able to have other threads running besides the thread the uses libevent. I don't need to be able to access libevent at all from more than one of them, but I'd really like to be able to have the subthreads not get killed when a signal comes in. If this goes in, it could IMO warrant a 1.3a; we really need this bug fixed, especially for BSD and OSX users. > There are still several caveats with threads. Ignoring the complex > idea of sharing an event_base between threads (need still has to be > proven...I've been way too busy with other things to run the > benchmarks I've been wanting to), these ones remain: > > 2. If you forget event_base_set on an event, it's associated with the > latest base created. This will probably work most of the time. It'd > be much less confusing if it consistently broke. How about an "event_clear_default_base()" function to force current_base to NULL, so that things will consistently break if called with the default base? > 3. Each new base created leaks the existing ev_signal_pair descriptors. > > 4. Signals are delivered to whatever event loop happens to see them > first. > > 6. You can't destroy an event_base. event_base_free() doesn't work? [...] > There's one subtlety to it. With my change, evsignal_process() runs > with signals unblocked, so timing is critical. The original code is > then racy: I agree that this is a subtle point; maybe the code needs a comment explaining the possible race issues. yrs, -- Nick Mathewson -------------- 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/20070222/5ab2603c/attachment.bin From toby.douglass at summerblue.net Fri Feb 23 18:43:11 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Fri Feb 23 18:42:27 2007 Subject: [Libevent-users] IOCP API Message-ID: <45DF7C0F.1010505@summerblue.net> Okay, so I've finished writing the IOCP code. I now need to finish the test/example application. When that's done, I'll upload. Might even be this weekend. Prototypes ========== 1. int socket_iocp_new( void **socket_iocp_state, size_t read_buffer_size, void (*accept_callback_function)(SOCKET socket, struct sockaddr *local_address, struct sockaddr *remote_address, void *listen_socket_user_state, void **per_socket_user_state), void (*recv_callback_function)(SOCKET socket, void *read_buffer, DWORD byte_count, void *per_socket_user_state), void (*send_callback_function)( SOCKET socket, void *per_socket_user_state, void *per_write_user_state ), void (*error_callback_function)(SOCKET socket, void *per_socket_user_state) ); 2. void socket_iocp_delete( void *socket_iocp_state ); 3. int socket_iocp_add_listen_socket( void *socket_iocp_state, SOCKET socket, size_t accept_socket_backlog, void *listen_user_state ); 4. int socket_iocp_add_connected_socket( void *socket_iocp_state, SOCKET socket, void *per_socket_user_state ); 5. int socket_iocp_issue_recv( void *socket_iocp_state, void *socket_iocp_socket_state ); 6. int socket_iocp_issue_sync_send( void *socket_iocp_state, void *socket_iocp_socket_state, void *write_buffer, DWORD number_bytes_to_write, void *per_write_user_state ); 7. int socket_iocp_issue_async_send( void *socket_iocp_state, void *socket_iocp_socket_state, void *write_buffer, DWORD number_bytes_to_write, void *per_write_user_state ); API Useage ========== First, call socket_iocp_new(). This returns the basic state the API uses. Each state represents a single IOCP object. When calling this function, you pass in four callback functions; one for accept, one for send, one for recv and one for error. Once you have this state, you can then add either listen sockets or connected sockets to the IOCP. If you add a listen socket, you specify how many ready sockets should be kept allocated on that listen socket. The API maintains that number of ready sockets. When an incoming connection occurs, the accept callback is called. At this point, the user can associate state of his own with that socket. If you add a connected socket, it's simply added to the IOCP. The user can pass in his own state to be associated with that socket. Sockets, once added, have no reads or writes issued on them; they'll do nothing until the user issues one of three IOCP send/recv functions in the API. The user can issue the IOCP API recv function on a socket. When that recv completes, the recv callback is called with the read buffer and the user's state. The user must call the IOCP recv function again for another read to be present and ready and outstanding on that socket. The user can issue either a "synchronous" or "asynchronous" write on a socket. A sync write requires no malloc, but requires the user to ensure he only has one write occurring at a time on a socket; he cannot issue another write until the current write has completed. When the write is issued, the user can provide state for that write. When the write completes, the write complete function is called, with both the state the user associated with that socket and the state the user associated with that write. An async write requires one malloc per call and permits the user to have an arbitrary number of concurrent writes occurring on a single socket. As with the sync write, the user can pass in a per-write state, and when a write completes, the write callback is called, with the state the user associated with the socket and the state associated with that write. Overall Usage ============= The idea is that the user calls the new() function once at program init. Then the user adds/removes sockets as necessary, and issues reads/writes as necessary, and services those reads/writes in the callback functions, using the per socket/per write state information. The user has to issue a new read on a socket, in the read callback, to continue reading from a socket. So there you go! Comments and thoughts, please. From slamb at slamb.org Sat Feb 24 14:46:20 2007 From: slamb at slamb.org (Scott Lamb) Date: Sat Feb 24 14:46:31 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> Message-ID: On Feb 22, 2007, at 6:32 PM, Niels Provos wrote: > Do you have an addition to the regression test that would allow me to > verify that the new code works as intended? If not, it would be most > appreciated :-) Happy Weekend, everyone. Looking at this again. There are two regression tests for this now: * test_simplesignal() tests a signal delivered while within select()/ poll()/kevent()/epoll()/whatever. * test_immediatesignal() tests a signal delivered between signal_add () and event_loop(). But you're referring to something more...proving that there would have been an evsignal_process() race if not for the reordering, right? That's hard to do through regression tests. I can think of only a couple ways to do that: (1) loop trying it many times, scheduling later delivery with alarms or through an additional thread (tests would depend on pthreads). Probably have to add some instrumentation to evsignal_process() to make it sleep at particular times to make it likely enough to happen on demand. (2) use debugging mechanisms to step through and deliver the signal at a particular time. I actually have done this programmatically before when proving a signal-handling library [*], but it was a lot of code and not exactly the most portable. Maybe it could be done more easily with gdb and expect, on at least gdb platforms. Would it help if I showed you a way to test it by hand? I've attached a simple test program that registers a handler for SIGUSR1 and SIGUSR2 which simply notes the signal was received. You can see the races I mention with gdb as follows: $ gcc -Wall sigtest.c -o sigtest -L.libs -levent $ LD_LIBRARY_PATH=.libs gdb ./sigtest ... (gdb) break evsignal_process Function "evsignal_process" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (evsignal_process) pending. (gdb) run Starting program: /home/slamb/svn/libevent/sigtest (no debugging symbols found) <<>> Breakpoint 2 at 0x2aaaaaabf4a0: file signal.c, line 165. Pending breakpoint "evsignal_process" resolved Program received signal SIGINT, Interrupt. 0x000000318a4cd9d3 in __epoll_wait_nocancel () from /lib64/libc.so.6 (gdb) signal SIGUSR1 Breakpoint 2, evsignal_process () at signal.c:165 (my line numbers are off because I've #ifdefed the two code blocks) <<>> (gdb) n 179 memset(evsigcaught, 0, sizeof(evsigcaught)); (gdb) signal SIGUSR2 Continuing with signal SIGUSR2. Received signal 10 Here you can see that it only acknowledged receipt of SIGUSR1; SIGUSR2 was lost. If you do the same thing at any point in my modified evsignal_process (), you find instead: (gdb) signal SIGUSR2 Continuing with signal SIGUSR2. Received signal 10 Breakpoint 2, evsignal_process () at signal.c:165 165 { (gdb) c Continuing. Received signal 12 [*] http://www.slamb.org/svn/repos/trunk/projects/sigsafe/tests/ race_checker/ -- Scott Lamb -------------- next part -------------- A non-text attachment was scrubbed... Name: sigtest.c Type: application/octet-stream Size: 463 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070224/9ec0216f/sigtest.obj From provos at citi.umich.edu Sat Feb 24 15:49:15 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat Feb 24 15:49:22 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> Message-ID: <850f7cbe0702241249l1ed91c46oac38ca110c818d7@mail.gmail.com> On 2/24/07, Scott Lamb wrote: > There are two regression tests for this now: Great. > But you're referring to something more...proving that there would > have been an evsignal_process() race if not for the reordering, > right? That's hard to do through regression tests. I can think of > only a couple ways to do that: I am really just looking for something that all of us can run every time we make a change to the library. Otherwise, it's really hard to be sure that one did not introduce unwanted side effects. I know that it's difficult to get complete coverage, but some tests for each new change are a very good practice. I'll have a look at your changes tomorrow. Thank you, Niels. From slamb at slamb.org Sat Feb 24 15:55:04 2007 From: slamb at slamb.org (Scott Lamb) Date: Sat Feb 24 15:55:10 2007 Subject: [Libevent-users] Sigprocmask vs pthread_sigprocmask In-Reply-To: <850f7cbe0702241249l1ed91c46oac38ca110c818d7@mail.gmail.com> References: <20070221084458.GY22682@totoro.wangafu.net> <20070221092927.GA9920@wilbur.25thandClement.com> <9438B2DF-3095-4371-B890-1E7CCA2FDD6E@slamb.org> <850f7cbe0702221832t2b68c4a5j7433c95e85639dc3@mail.gmail.com> <850f7cbe0702241249l1ed91c46oac38ca110c818d7@mail.gmail.com> Message-ID: <22186075-3B91-4194-9139-29471BA8252B@slamb.org> On Feb 24, 2007, at 12:49 PM, Niels Provos wrote: > I know that > it's difficult to get complete coverage, but some tests for each new > change are a very good practice. Well, at least the test_immediatesignal() fails with the old code and passes with the new code. I would love to get coverage of the race condition as well...but I don't have a good way to do it. I had this same discussion with the Twisted people not too long ago. I kind of think full coverage is a good goal to shoot for, but essentially impossible to achieve. -- Scott Lamb From toby.douglass at summerblue.net Sun Feb 25 18:07:23 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Sun Feb 25 18:06:18 2007 Subject: [Libevent-users] IOCP Message-ID: <45E216AB.9050002@summerblue.net> Well, getting there. Have written the test app, currently debugging it and the API. From christian at yetisoft.org Mon Feb 26 17:57:55 2007 From: christian at yetisoft.org (Christian Ress) Date: Mon Feb 26 17:58:19 2007 Subject: [Libevent-users] multiple calls of event_dispatch() Message-ID: <45E365F3.8000702@yetisoft.org> Hello, I stumbled across libevent and it seems to fit my needs very well. However, I wonder if this is side-effect free: second_cb(..) { .. } first_cb(..) { .. struct event newev; evtimer_set(&newev, second_cb, NULL); event_base_set(ev_base, &newev); event_add(&newev, &tv); event_base_dispatch(ev_base); } main() { .. ev_base = event_init(); evtimer_set(ev, first_cb, NULL); event_add(ev, &tv); event_base_dispatch(ev_base); } The point of this is creating new events 'on demand', but since I'm calling event_dispatch when being called by event_loop, I wonder if this might lead to recursion issues or similar bad behaviour. I hope someone can clarify this :) Thanks, Christian From oz at nixil.net Mon Feb 26 18:54:04 2007 From: oz at nixil.net (Phil Oleson) Date: Mon Feb 26 18:54:08 2007 Subject: [Libevent-users] multiple calls of event_dispatch() In-Reply-To: <45E365F3.8000702@yetisoft.org> References: <45E365F3.8000702@yetisoft.org> Message-ID: <20070226235404.GA29634@nixil.net> Comments inline.. On Mon, Feb 26, 2007 at 11:57:55PM +0100, Christian Ress wrote: > Hello, > > I stumbled across libevent and it seems to fit my needs very well. > However, I wonder if this is side-effect free: > > second_cb(..) { .. } > first_cb(..) { > .. > struct event newev; allocate your event struct in the callback as the storage will disapear. > evtimer_set(&newev, second_cb, NULL); > event_base_set(ev_base, &newev); > event_add(&newev, &tv); > > event_base_dispatch(ev_base); no need to re-run the dispatch call here as the one in main() is the main loop and will pick up after the return of the callback. > } > > main() { > .. > ev_base = event_init(); > evtimer_set(ev, first_cb, NULL); > event_add(ev, &tv); > > event_base_dispatch(ev_base); > } > > The point of this is creating new events 'on demand', but since I'm > calling event_dispatch when being called by event_loop, I wonder if this > might lead to recursion issues or similar bad behaviour. as stated above.. there is no need to call event_base_dispatch() again, so there wont be a problem. If you really need to go through one pass then use event_loop()/event_base_loop() -Phil. From slamb at slamb.org Mon Feb 26 18:56:01 2007 From: slamb at slamb.org (Scott Lamb) Date: Mon Feb 26 18:56:08 2007 Subject: [Libevent-users] multiple calls of event_dispatch() In-Reply-To: <45E365F3.8000702@yetisoft.org> References: <45E365F3.8000702@yetisoft.org> Message-ID: On Feb 26, 2007, at 2:57 PM, Christian Ress wrote: > Hello, > > I stumbled across libevent and it seems to fit my needs very well. > However, I wonder if this is side-effect free: > > second_cb(..) { .. } > first_cb(..) { > .. > struct event newev; > evtimer_set(&newev, second_cb, NULL); > event_base_set(ev_base, &newev); > event_add(&newev, &tv); > > event_base_dispatch(ev_base); > } > > main() { > .. > ev_base = event_init(); > evtimer_set(ev, first_cb, NULL); > event_add(ev, &tv); > > event_base_dispatch(ev_base); > } > > The point of this is creating new events 'on demand', but since I'm > calling event_dispatch when being called by event_loop, I wonder if > this might lead to recursion issues or similar bad behaviour. > > I hope someone can clarify this :) First, keep in mind something that tripped up me when I first started using libevent - the "struct event" you pass to event_add is not duplicated, but rather directly linked into the event_base's queues. So if it's a timeout, it needs to live until it fires (or forever with EV_PERSIST) or you manually call event_del(). There are a lot of reasons that might not happen in the next invocation of event_base_dispatch(), so this code seems dangerous. And second...while I don't see anything off-hand in libevent that would break based on this recursion, I don't think it was intended to be used that way, and you always risk stack overflows if you don't have a way to bound your recursion. You can create new events 'on demand' with event_once. Which isn't magic - it just internally allocates a new struct event on the heap that adds a callback which - after calling your callback - frees the struct event. You could accomplish the same thing yourself: void first_cb(int fd, short events, void *arg) { struct event *newev; int res; ... newev = malloc(sizeof(struct event)); ...newev == NULL error handling goes here... evtimer_set(newev, ...); res = event_add(&newev, &tv); ...event_add error handling goes here... } void second_cb(int fd, short events, void *arg) { struct event *myev = arg; ... free(myev); } -- Scott Lamb From provos at citi.umich.edu Mon Feb 26 23:26:33 2007 From: provos at citi.umich.edu (Niels Provos) Date: Mon Feb 26 23:26:44 2007 Subject: [Libevent-users] example code for libevent's http layer Message-ID: <850f7cbe0702262026h2d9da407p3196ba27ff0da889@mail.gmail.com> Hi everyone, I recently released SpyBye, http://www.spybye.org/. Although, it fulfills a real and practical purpose, it was mostly an exercise in testing libevent's HTTP layer. It might be an interesting code example for some of you. You can download the source code from: http://www.monkey.org/~provos/spybye/ On the other hand, if you like the concept, feel free to add your diggs: http://digg.com/security/SpyBye_Finding_Malware_in_Web_Sites Niels. From rfistman at gmail.com Tue Feb 27 06:01:48 2007 From: rfistman at gmail.com (Rhythmic Fistman) Date: Tue Feb 27 06:01:53 2007 Subject: [Libevent-users] Re: IOCP API Message-ID: <131e28b50702270301l6f0db109u5fb52fe92955fc33@mail.gmail.com> > From: Toby Douglass > Okay, so I've finished writing the IOCP code. > > I now need to finish the test/example application. > > When that's done, I'll upload. Might even be this weekend. > > Prototypes > ========== > 1. int socket_iocp_new( void **socket_iocp_state, size_t > read_buffer_size, void (*accept_callback_function)(SOCKET socket, struct > sockaddr *local_address, struct sockaddr *remote_address, void > *listen_socket_user_state, void **per_socket_user_state), void > (*recv_callback_function)(SOCKET socket, void *read_buffer, DWORD > byte_count, void *per_socket_user_state), void > (*send_callback_function)( SOCKET socket, void *per_socket_user_state, > void *per_write_user_state ), void (*error_callback_function)(SOCKET > socket, void *per_socket_user_state) ); [...] > Comments and thoughts, please. It looks to me like all your callbacks are asynchronous. Is that the case? If so you're probably working off the standard iocp example code which spawns num_cpus/2 or num_cpus*2 or f(num_cpus) threads, however that's the sort of choice that I think should be left to user, exposing instead an interface int iocp_wait(long timeout) which calls the callbacks. This lets the user choose the "asynchronicity" of their app, i.e. they can write singlethreaded mutex-less iocp code. As an interface socket_iocp_new is a tiny bit "busy" as it wraps almost every function that iocps understand. A bit of factoring might make it more friendly. A control-block style interface could also help as it cuts down the argument list and makes the "per socket user state" implicit (it actually makes it per iocp operation user state). It also gives you two way communication (user -> iocp library -> user in callback) typedef struct { SOCKET s; /* <- */ char* buf; /* <-, -> */ long nbytes; /* <-, -> */ void (*iocp_read_callback)(iocp_state* st, iocp_read* control_block); /* <- */ } iocp_read; The user can piggy back per operation data like so: typedef struct { iocp_read control_block; /* extra stuff here */ }my_iocp_read; void my_iocp_read_callback)(iocp_state* st, iocp_read* control_block) { my_iocp_read* my_cb = (my_iocp_read*)control_block; /* respond, requeue, whatever */ } RF -- felix: lightweight threads, HOFs and game scripting. svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix From toby.douglass at summerblue.net Tue Feb 27 09:58:36 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Tue Feb 27 09:58:41 2007 Subject: [Libevent-users] Re: IOCP API In-Reply-To: <131e28b50702270301l6f0db109u5fb52fe92955fc33@mail.gmail.com> References: <131e28b50702270301l6f0db109u5fb52fe92955fc33@mail.gmail.com> Message-ID: <26523.82.195.181.130.1172588316.squirrel@webmail.serve.com> >> I now need to finish the test/example application. >> When that's done, I'll upload. Might even be this weekend. I've been working away. Got a wierd bug which is holding things up. >> Prototypes >> ========== >> 1. int socket_iocp_new( void **socket_iocp_state, size_t >> read_buffer_size, void (*accept_callback_function)(SOCKET socket, struct >> sockaddr *local_address, struct sockaddr *remote_address, void >> *listen_socket_user_state, void **per_socket_user_state), void >> (*recv_callback_function)(SOCKET socket, void *read_buffer, DWORD byte_count, void *per_socket_user_state), void >> (*send_callback_function)( SOCKET socket, void *per_socket_user_state, void *per_write_user_state ), void (*error_callback_function)(SOCKET socket, void *per_socket_user_state) ); > It looks to me like all your callbacks are asynchronous. Yes. > Is that the case? If so you're probably working off the standard iocp example code which spawns num_cpus/2 or num_cpus*2 or > f(num_cpus) threads, Yup, CPU count * 2. > however that's the sort of choice that > I think should be left to user, exposing instead an interface > int iocp_wait(long timeout) which calls the callbacks. Do you mean that the user goes off in his code, does his stuff, and when he's ready to deal with IOCP stuff, he calls iocp_wait() and the API is then free to call the callbacks, but it will be using the users thread to do this, and after "long timeout" has expired, iocp_wait() returns and the user continues with his code till he next calls iocp_wait()? > This > lets the user choose the "asynchronicity" of their app, > i.e. they can write singlethreaded mutex-less iocp code. Would it be possible to have a single threaded app which is trying to do C10K? > As an interface socket_iocp_new is a tiny bit "busy" as it > wraps almost every function that iocps understand. Yes. In fact, it's the longest prototype I've ever written. OTOH, when you actually write it, it's only six arguments. > A bit of > factoring might make it more friendly. A control-block style > interface could also help as it cuts down the argument list > and makes the "per socket user state" implicit (it actually > makes it per iocp operation user state). It also gives you > two way communication (user -> iocp library -> user in callback) > > typedef struct { > SOCKET s; /* <- */ > char* buf; /* <-, -> */ > long nbytes; /* <-, -> */ > void (*iocp_read_callback)(iocp_state* st, iocp_read* control_block); /* > <- */ > } iocp_read; > > The user can piggy back per operation data like so: > typedef struct { > iocp_read control_block; > /* extra stuff here */ > }my_iocp_read; > > void > my_iocp_read_callback)(iocp_state* st, iocp_read* control_block) { > my_iocp_read* my_cb = (my_iocp_read*)control_block; > /* respond, requeue, whatever */ > } This converts a large one-off complexity in the new() function into a smaller complexity which is required for every function call. Separately, ould it be useful to have per read state in the way that per write state exists? it seems to me since that reads are serial (only one read at a time per socket) that state will be kept by the user in the per socket state. From christian at yetisoft.org Tue Feb 27 14:05:44 2007 From: christian at yetisoft.org (Christian Ress) Date: Tue Feb 27 14:06:03 2007 Subject: [Libevent-users] multiple calls of event_dispatch() In-Reply-To: References: <45E365F3.8000702@yetisoft.org> Message-ID: <45E48108.1040802@yetisoft.org> Scott Lamb wrote: > First, keep in mind something that tripped up me when I first started > using libevent - the "struct event" you pass to event_add is not > duplicated, but rather directly linked into the event_base's queues. Once you said it I was scared that I've thought differently. That also explains why I called event_base_dispatch() again: Without it the event loop created in main() would segfault when trying to access the new event structure because it was destroyed once the callback block was left. When allocating the struct with malloc and using it, it works out fine. > > You can create new events 'on demand' with event_once. Which isn't magic > - it just internally allocates a new struct event on the heap that adds > a callback which - after calling your callback - frees the struct event. > You could accomplish the same thing yourself: event_once seems to be a nice alternative, I'll try around with it. Thanks to both of you, Christian From toby.douglass at summerblue.net Tue Feb 27 18:20:23 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Tue Feb 27 18:18:51 2007 Subject: [Libevent-users] cha-ching! Message-ID: <45E4BCB7.6030507@summerblue.net> Sorted out weird bug. Will do a release this weekend. From toby.douglass at summerblue.net Tue Feb 27 18:44:01 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Tue Feb 27 18:43:18 2007 Subject: [Libevent-users] cha-ching! In-Reply-To: <5EF9DB461429644382393A30DE0060B402B33C0F@xmb-sjc-21b.amer.cisco.com> References: <45E4BCB7.6030507@summerblue.net> <5EF9DB461429644382393A30DE0060B402B33C0F@xmb-sjc-21b.amer.cisco.com> Message-ID: <45E4C241.1030403@summerblue.net> Sravan Vadlakonda (svadlako) wrote: > Toby Douglass wrote: >> Sorted out weird bug. >> >> Will do a release this weekend. > Hi Toby, > Can you please say what the bug is that you observed ? Not really a bug as such - a documentation bug, if you like. If you call AcceptEx() and specify a non-zero read buffer size, GetQueuedCompletionStatus() will NOT return on a connect. It will only return when some data is sent. My test app currently only connects, it doesn't send any data. So I was connecting a dozen sockets and wondering why the accept notification wasn't occurring - and my code relies on that notification to know when to resupply the listen socket with ready-accept sockets. (If you had a lot of no-data connects, you would execute a DOS attack on the server, since you would empty the pool of ready-accept sockets, as the server would never know to replenish). I'm wondering now how many people have accidentally implemented this vulnerability). The docs don't explicitly mention that the accept notification *won't* occur until some data has been sent. From provos at citi.umich.edu Tue Feb 27 23:03:23 2007 From: provos at citi.umich.edu (Niels Provos) Date: Tue Feb 27 23:03:28 2007 Subject: [Libevent-users] Re: [Patch] Install autocon