From provos at citi.umich.edu Wed Jan 3 02:11:32 2007 From: provos at citi.umich.edu (Niels Provos) Date: Wed Jan 3 02:12:29 2007 Subject: [Libevent-users] Re: [Patch] Avoid conflicts with platform strlcpy In-Reply-To: <20061227171024.GB12940@totoro.wangafu.net> References: <20061227171024.GB12940@totoro.wangafu.net> Message-ID: <850f7cbe0701022311l1e463447wbb13fb4569753387@mail.gmail.com> Thank you. Submitted to trunk. Niels. On 12/27/06, Nick Mathewson wrote: > Hi, all! This patch renames the strlcpy defined in strlcpy.c so that > it no longer messes with tests by other programs for the presence of a > strlcpy function. This patch also fixes compilation on mingw, and > fixes a warning in regress_http.c. > > cheers, > -- > Nick Mathewson > > > From Shanti.Subramanyam at Sun.COM Wed Jan 3 13:37:38 2007 From: Shanti.Subramanyam at Sun.COM (Shanti Subramanyam) Date: Wed Jan 3 13:37:39 2007 Subject: [Libevent-users] Re: [PATCHES] libevent portability, Sun C compiler In-Reply-To: <20070103022515.GA23104@cs.rmit.edu.au> References: <20070103022515.GA23104@cs.rmit.edu.au> Message-ID: <267E5577-A6B7-4241-B028-59960ADBBA06@Sun.COM> Emil, Thanks very much for your patches. We have finally built libevent successfully on Solaris 10 using Sun Studio 11 compiler (downloadable for free) and here are the changes that had to be made : 1) Edit http.c and event_tagging.c to change '__inline' to 'inline' as mentioned previously 2) Edit event.h to add the following : #ifdef HAVE_CONFIG_H #include "config.h" #endif 3) I did not make any changes to configure.in (couldn't get your suggested changes to work). Instead, call configure as follows : ./configure CFLAGS= "-fast -xipo -xtarget=generic" LDFLAGS="- lnsl -lresolv" 1) and 2) above needs to be fixed in the generic source tree. It would also be great if test/regress.gen.* were supplied, so that one doesn't require python to be installed. Shanti On Jan 2, 2007, at 6:25 PM, Emil Mikulic wrote: > [sorry for the re-post, the first one went out without a Subject: > header > because my fingers got ahead of me...] > > Hi there, > > I'm building libevent (SVN HEAD) with Sun C 5.8: > > $ cc -V > cc: Sun C 5.8 Patch 121015-03 2006/10/18 > usage: cc [ options] files. Use 'cc -flags' for details > $ uname -srvmp > SunOS 5.10 Generic_118822-30 sun4u sparc > > I've run into a handful of minor portability issues: > > > > ______________________________________________________________________ > __ > 0) Minor glitch in autogen.sh: > > --- autogen.sh (revision 305) > +++ autogen.sh (working copy) > @@ -1,6 +1,6 @@ > #!/bin/sh > LIBTOOLIZE=libtoolize > -if [ "$(uname)" == "Darwin" ] ; then > +if [ "$(uname)" = "Darwin" ] ; then > LIBTOOLIZE=glibtoolize > fi > aclocal && \ > > > > ______________________________________________________________________ > __ > 1) As Shanti already pointed out in > http://monkeymail.org/archives/libevent-users/2006-December/ > 000439.html, > two files use __inline. I believe this is non-standard (a GCC-ism) > and > chokes the Sun compiler. Other files already use the more standard > "inline": > > emil@goanna:~/levent/trunk/libevent> grep inline * > buffer.c:static inline void > evdns.c:static inline int > event_tagging.c:static int __inline > http.c:static __inline void > rtsig.c:static inline int > rtsig.c:static inline int > rtsig.c:static inline int > rtsig.c:static inline int > > Could you please commit something like the following? > > Index: http.c > =================================================================== > --- http.c (revision 305) > +++ http.c (working copy) > @@ -1512,7 +1512,7 @@ > > /* Requires that headers and response code are already set up */ > > -static __inline void > +static inline void > evhttp_send(struct evhttp_request *req, struct evbuffer *databuf) > { > struct evhttp_connection *evcon = req->evcon; > Index: event_tagging.c > =================================================================== > --- event_tagging.c (revision 305) > +++ event_tagging.c (working copy) > @@ -149,7 +149,7 @@ > EVBUFFER_LENGTH(_buf)); > } > > -static int __inline > +static int inline > decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf, > int dodrain) > { > u_int32_t number = 0; > > > > ______________________________________________________________________ > __ > 2) __func__ is not detected correctly by configure: > $ ./configure > [...] > checking whether our compiler supports __func__... no > checking whether our compiler supports __FUNCTION__... no > [...] > > from config.log: > | int > | main () > | { > | void foo() { const char *cp = __func__; } > | ; > | return 0; > | } > [...] > "conftest.c", line 63: syntax error before or at: { > "conftest.c", line 64: warning: syntax error: empty declaration > "conftest.c", line 65: syntax error before or at: return > "conftest.c", line 65: warning: syntax error: empty declaration > > I would suggest: > --- configure.in (revision 305) > +++ configure.in (working copy) > @@ -355,12 +355,12 @@ > > AC_MSG_CHECKING([whether our compiler supports __func__]) > AC_TRY_COMPILE([], > - [void foo() { const char *cp = __func__; }], > + [const char *cp = __func__;], > AC_MSG_RESULT([yes]), > AC_MSG_RESULT([no]) > AC_MSG_CHECKING([whether our compiler supports __FUNCTION__]) > AC_TRY_COMPILE([], > - [void foo() { const char *cp = __FUNCTION__; }], > + [const char *cp = __FUNCTION__;], > AC_MSG_RESULT([yes]) > AC_DEFINE(__func__, __FUNCTION__, > [Define to appropriate substitue if compiler doesnt have > __func__]), > > Yielding: > $ ./configure > [...] > checking whether our compiler supports __func__... yes > > (from previous discussions with the GNUPG maintainers, my > understanding > is that __func__ is standard C99 while __FUNCTION__ is a GCC-ism) > > > > ______________________________________________________________________ > __ > 3) event.h uses u_int8_t and friends instead of > uint8_t and friends > > None of the Solaris system headers define the u_* variants. > Should all instances of u_* in event.h be changed to u* ? > > > > ______________________________________________________________________ > __ > 4) http.c uses MIN() without declaring it as evdns.c does: > emil@goanna:~/levent/trunk/libevent> gmake http.o > cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -g -c http.c > "http.c", line 871: warning: implicit function declaration: MIN > > Fix: > --- http.c (revision 305) > +++ http.c (working copy) > @@ -73,6 +73,9 @@ > #undef timeout_pending > #undef timeout_initialized > > +#undef MIN > +#define MIN(a,b) ((a)<(b)?(a):(b)) > + > #include "event.h" > #include "evhttp.h" > #include "log.h" > > > > ______________________________________________________________________ > __ > 5) As Shanti pointed out in the aforementioned mailing list post, the > build breaks on libevent/sample/event-test: > > emil@goanna:~/levent/trunk/libevent/sample> gmake > /bin/bash ../libtool --tag=CC --mode=link cc -I../compat -o > event-test event-test.o ../libevent.la -lsocket > cc -I../compat -o .libs/event-test event-test.o ../.libs/ > libevent.so -lsocket -R/usr/local/lib > Undefined first referenced > symbol in file > inet_aton ../.libs/libevent.so > ld: fatal: Symbol referencing errors. No output written to .libs/ > event-test > > Solaris needs -lresolv as well as -lsocket. > > I would suggest: > --- configure.in (revision 305) > +++ configure.in (working copy) > @@ -36,6 +36,7 @@ > > dnl Checks for libraries. > AC_CHECK_LIB(socket, socket) > +AC_CHECK_LIB(resolv, inet_aton) > > dnl Checks for header files. > AC_HEADER_STDC > > -- > Emil Mikulic, UNIX System Administrator | Ext: 55202 > Technical Services Group | PGP: 8E4C5D35 > Computer Science, RMIT University | Room 10.10.17 From Shanti.Subramanyam at Sun.COM Wed Jan 3 15:28:51 2007 From: Shanti.Subramanyam at Sun.COM (Shanti Subramanyam) Date: Wed Jan 3 15:29:01 2007 Subject: [Libevent-users] Re: [PATCHES] libevent portability, Sun C compiler In-Reply-To: <267E5577-A6B7-4241-B028-59960ADBBA06@Sun.COM> References: <20070103022515.GA23104@cs.rmit.edu.au> <267E5577-A6B7-4241-B028-59960ADBBA06@Sun.COM> Message-ID: It turns out that I can't really fix event.h as proposed below. The client cannot find config.h. So I resorted to editing event.h and replacing all the 'u_int*' with 'uint*' as suggested by Emil. If someone can think up of a more elegant fix to resolve this problem, that would be great. Shanti On Jan 3, 2007, at 10:37 AM, Shanti Subramanyam wrote: > Emil, > Thanks very much for your patches. > We have finally built libevent successfully on Solaris 10 using > Sun Studio 11 compiler (downloadable for free) and here are the > changes that had to be made : > > 1) Edit http.c and event_tagging.c to change '__inline' to 'inline' > as mentioned previously > > 2) Edit event.h to add the following : > > #ifdef HAVE_CONFIG_H > #include "config.h" > #endif > > 3) I did not make any changes to configure.in (couldn't get your > suggested changes to work). > Instead, call configure as follows : > ./configure CFLAGS= "-fast -xipo -xtarget=generic" LDFLAGS="- > lnsl -lresolv" > > > 1) and 2) above needs to be fixed in the generic source tree. It > would also be great if test/regress.gen.* were supplied, so that > one doesn't require python to be installed. > > Shanti > > > On Jan 2, 2007, at 6:25 PM, Emil Mikulic wrote: > >> [sorry for the re-post, the first one went out without a Subject: >> header >> because my fingers got ahead of me...] >> >> Hi there, >> >> I'm building libevent (SVN HEAD) with Sun C 5.8: >> >> $ cc -V >> cc: Sun C 5.8 Patch 121015-03 2006/10/18 >> usage: cc [ options] files. Use 'cc -flags' for details >> $ uname -srvmp >> SunOS 5.10 Generic_118822-30 sun4u sparc >> >> I've run into a handful of minor portability issues: >> >> >> >> _____________________________________________________________________ >> ___ >> 0) Minor glitch in autogen.sh: >> >> --- autogen.sh (revision 305) >> +++ autogen.sh (working copy) >> @@ -1,6 +1,6 @@ >> #!/bin/sh >> LIBTOOLIZE=libtoolize >> -if [ "$(uname)" == "Darwin" ] ; then >> +if [ "$(uname)" = "Darwin" ] ; then >> LIBTOOLIZE=glibtoolize >> fi >> aclocal && \ >> >> >> >> _____________________________________________________________________ >> ___ >> 1) As Shanti already pointed out in >> http://monkeymail.org/archives/libevent-users/2006-December/ >> 000439.html, >> two files use __inline. I believe this is non-standard (a GCC- >> ism) and >> chokes the Sun compiler. Other files already use the more standard >> "inline": >> >> emil@goanna:~/levent/trunk/libevent> grep inline * >> buffer.c:static inline void >> evdns.c:static inline int >> event_tagging.c:static int __inline >> http.c:static __inline void >> rtsig.c:static inline int >> rtsig.c:static inline int >> rtsig.c:static inline int >> rtsig.c:static inline int >> >> Could you please commit something like the following? >> >> Index: http.c >> =================================================================== >> --- http.c (revision 305) >> +++ http.c (working copy) >> @@ -1512,7 +1512,7 @@ >> >> /* Requires that headers and response code are already set up */ >> >> -static __inline void >> +static inline void >> evhttp_send(struct evhttp_request *req, struct evbuffer *databuf) >> { >> struct evhttp_connection *evcon = req->evcon; >> Index: event_tagging.c >> =================================================================== >> --- event_tagging.c (revision 305) >> +++ event_tagging.c (working copy) >> @@ -149,7 +149,7 @@ >> EVBUFFER_LENGTH(_buf)); >> } >> >> -static int __inline >> +static int inline >> decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf, >> int dodrain) >> { >> u_int32_t number = 0; >> >> >> >> _____________________________________________________________________ >> ___ >> 2) __func__ is not detected correctly by configure: >> $ ./configure >> [...] >> checking whether our compiler supports __func__... no >> checking whether our compiler supports __FUNCTION__... no >> [...] >> >> from config.log: >> | int >> | main () >> | { >> | void foo() { const char *cp = __func__; } >> | ; >> | return 0; >> | } >> [...] >> "conftest.c", line 63: syntax error before or at: { >> "conftest.c", line 64: warning: syntax error: empty declaration >> "conftest.c", line 65: syntax error before or at: return >> "conftest.c", line 65: warning: syntax error: empty declaration >> >> I would suggest: >> --- configure.in (revision 305) >> +++ configure.in (working copy) >> @@ -355,12 +355,12 @@ >> >> AC_MSG_CHECKING([whether our compiler supports __func__]) >> AC_TRY_COMPILE([], >> - [void foo() { const char *cp = __func__; }], >> + [const char *cp = __func__;], >> AC_MSG_RESULT([yes]), >> AC_MSG_RESULT([no]) >> AC_MSG_CHECKING([whether our compiler supports __FUNCTION__]) >> AC_TRY_COMPILE([], >> - [void foo() { const char *cp = __FUNCTION__; }], >> + [const char *cp = __FUNCTION__;], >> AC_MSG_RESULT([yes]) >> AC_DEFINE(__func__, __FUNCTION__, >> [Define to appropriate substitue if compiler doesnt have >> __func__]), >> >> Yielding: >> $ ./configure >> [...] >> checking whether our compiler supports __func__... yes >> >> (from previous discussions with the GNUPG maintainers, my >> understanding >> is that __func__ is standard C99 while __FUNCTION__ is a GCC-ism) >> >> >> >> _____________________________________________________________________ >> ___ >> 3) event.h uses u_int8_t and friends instead of >> uint8_t and friends >> >> None of the Solaris system headers define the u_* variants. >> Should all instances of u_* in event.h be changed to u* ? >> >> >> >> _____________________________________________________________________ >> ___ >> 4) http.c uses MIN() without declaring it as evdns.c does: >> emil@goanna:~/levent/trunk/libevent> gmake http.o >> cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -g -c http.c >> "http.c", line 871: warning: implicit function declaration: MIN >> >> Fix: >> --- http.c (revision 305) >> +++ http.c (working copy) >> @@ -73,6 +73,9 @@ >> #undef timeout_pending >> #undef timeout_initialized >> >> +#undef MIN >> +#define MIN(a,b) ((a)<(b)?(a):(b)) >> + >> #include "event.h" >> #include "evhttp.h" >> #include "log.h" >> >> >> >> _____________________________________________________________________ >> ___ >> 5) As Shanti pointed out in the aforementioned mailing list post, the >> build breaks on libevent/sample/event-test: >> >> emil@goanna:~/levent/trunk/libevent/sample> gmake >> /bin/bash ../libtool --tag=CC --mode=link cc -I../compat -o >> event-test event-test.o ../libevent.la -lsocket >> cc -I../compat -o .libs/event-test event-test.o ../.libs/ >> libevent.so -lsocket -R/usr/local/lib >> Undefined first referenced >> symbol in file >> inet_aton ../.libs/libevent.so >> ld: fatal: Symbol referencing errors. No output written to .libs/ >> event-test >> >> Solaris needs -lresolv as well as -lsocket. >> >> I would suggest: >> --- configure.in (revision 305) >> +++ configure.in (working copy) >> @@ -36,6 +36,7 @@ >> >> dnl Checks for libraries. >> AC_CHECK_LIB(socket, socket) >> +AC_CHECK_LIB(resolv, inet_aton) >> >> dnl Checks for header files. >> AC_HEADER_STDC >> >> -- >> Emil Mikulic, UNIX System Administrator | Ext: 55202 >> Technical Services Group | PGP: 8E4C5D35 >> Computer Science, RMIT University | Room 10.10.17 > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From pdarick at yahoo.com Wed Jan 3 18:21:49 2007 From: pdarick at yahoo.com (R B) Date: Wed Jan 3 18:28:33 2007 Subject: [Libevent-users] (no subject) Message-ID: <305751.44517.qm@web55415.mail.re4.yahoo.com> 1.2a and trunk-20060103, cygwin, win2K. Using libevent as an http server does not always work when client is sending its stuff in small packets. Testcase: use notepad->clipboard->telnet, with the following request: POST /xyz.php HTTP/1.0 Host: 127.0.0.1 User-Agent: Mozilla/4.0 Accept: */* Pragma: no-cache Cache-Control: no-cache Content-Type: application/octet-stream Content-Length: 65 Connection: close 1qwertyuiop 2qwertyuiop 3qwertyuiop 4qwertyuiop 5qwertyuiop Most times the handler registered with evhttp_set_cb() is called with just one or two lines as payload. char buf[200+1]; void cb(struct evhttp_request *req, void *arg) { int len = evbuffer_remove(req->input_buffer, buffer, sizeof(buffer)-1); buffer[len] = 0; fprintf(stderr, "got %d bytes {%s}\n", len, printable(buffer).Buffer()); } sample output: "got 23 bytes {1qwertyuiop[13][10]2qwertyuio}" Tracing: evhttp_get_body_length() enters the last else (content_length != NULL) req->ntoread = strtol(...) is 65 evhttp_get_body() req->ntoread == 65 EVBUFFER_LENGTH(evcon->input_buffer) == 42 if (req->ntoread > 0) req->ntoread -= EVBUFFER_LENGTH(evcon->input_buffer); ^^^ now req->ntoread = 23 evhttp_read() ... n = evbuffer_read(buf, fd, -1); len = EVBUFFER_LENGTH(buf); event_debug(("%s: got %d on %d; len=%d req->ntoread=%d\n", __func__, n, fd, len, req->ntoread)); prints: [debug] evhttp_read: got 23 on 6; len=65 req->ntoread=23 ... } else if (len >= req->ntoread) { /* Completed content length */ ^^^ oops. not really. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From slamb at slamb.org Thu Jan 4 19:10:15 2007 From: slamb at slamb.org (Scott Lamb) Date: Thu Jan 4 19:12:28 2007 Subject: [Libevent-users] looking for a swig interface for libevent In-Reply-To: <55193.81.242.147.176.1167070585.squirrel@mail.opensource4you.com> References: <55193.81.242.147.176.1167070585.squirrel@mail.opensource4you.com> Message-ID: On Dec 25, 2006, at 10:16 AM, william@opensource4you.com wrote: > I'm python developer and using libevent via pyevent (pyrex). > But, is there any one having a Swig interface for libevent ? Why would you want one? If pyevent works, what makes you think a swig wrapped would be better? I haven't been impressed with swig, and apparently Guido van Rossum hasn't either: "I've yet to see an extension module using SWIG that doesn't make me think it was a mistake to use SWIG instead of manually written wrappers. The extra time paid upfront to create hand-crafted wrappers is gained back hundredfold by time saved debugging the SWIG-generated code later." http://www.artima.com/weblogs/viewpost.jsp?thread=95863 -- Scott Lamb From philip at esper-digital.net Fri Jan 12 03:10:19 2007 From: philip at esper-digital.net (Philip Lewis) Date: Fri Jan 12 03:10:57 2007 Subject: [Libevent-users] [Patch] http server high port/getaddrinfo bug Message-ID: make_socket() in http.c takes the port as a short instead of an unsigned short, so ports higher than 32767 become a negative number in the string given to getaddrinfo(), which fails. Also, getaddrinfo() uses the return code instead of errno, so it fails with "[warn] getaddrinfo: Success". getnameinfo() also returns errors this way. Patch fixes both. -------------- next part -------------- A non-text attachment was scrubbed... Name: http-highport-test.patch Type: application/octet-stream Size: 769 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070112/ca3e5378/http-highport-test-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: http-highport-fix.patch Type: application/octet-stream Size: 2821 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070112/ca3e5378/http-highport-fix-0001.obj From glen at llnw.com Fri Jan 12 08:59:22 2007 From: glen at llnw.com (Glen Hein) Date: Fri Jan 12 09:06:10 2007 Subject: [Libevent-users] new member Message-ID: <00d401c73651$dce4edf0$6401a8c0@GHDualLaptop> Hello, I am doing research for a project that may follow an event-driven multi-threaded model with heavy disk and network I/O. The platform will be FreeBSD and Linux. Overall, we are seeking a C10K solution. I started reading through the libevent source and noticed several comments about not being thread-safe. However, I have seen references to other projects that are multi-threaded and use libevent. I need to explore libevent and determine if it is viable for my project. Have there been discussions on threading issues in the mailing list archive? Is there another source of information on threads and libevent? Thanks, Glen Hein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070112/c5196c9b/attachment.htm From sgrimm at facebook.com Fri Jan 12 10:16:30 2007 From: sgrimm at facebook.com (Steven Grimm) Date: Fri Jan 12 10:16:23 2007 Subject: [Libevent-users] new member In-Reply-To: <00d401c73651$dce4edf0$6401a8c0@GHDualLaptop> References: <00d401c73651$dce4edf0$6401a8c0@GHDualLaptop> Message-ID: <45A7A64E.8020601@facebook.com> As the guy who added thread support to memcached, I feel qualified to answer this one: What libevent doesn't support is sharing a libevent instance across threads. It works just fine to use libevent in a multithreaded process where only one thread is making libevent calls. What also works, and this is what I did in memcached, is to use multiple instances of libevent. Each call to event_init() will give you back an "event base," which you can think of as a handle to a libevent instance. (That's documented in the current manual page, but NOT in the older manpage on the libevent home page.) You can have multiple threads each with its own event base and everything works fine, though you probably don't want to install signal handlers on more than one thread. In the case of memcached, I allocate one event base per thread at startup time. One thread handles the TCP listen socket; when a new request comes in, it calls accept() then hands the file descriptor to another thread to handle from that point on -- that is, each client is bound to a particular thread. All you have to do is call event_base_set() after you call event_set() and before you call event_add(). Unfortunately, you pretty much have to use pipe() to communicate between libevent threads, That's a limitation, and honestly it's a pretty big one: it makes a master/worker thread architecture, where one thread handles all the I/O, much less efficient than you'd like. My initial implementation in memcached used an architecture like that and it chewed lots of CPU time. That's not really libevent's fault -- no UNIX-ish system I'm aware of has an equivalent to the Windows WaitForMultipleObjects API that allows you to wake up on semaphores / condition variables and on input from the network. Without that, any solution is going to end up using pipes (or maybe signals, which have their own set of issues in a multithreaded context) to wake up the libevent threads. -Steve Glen Hein wrote: > > Hello, > > > > I am doing research for a project that may follow an event-driven > multi-threaded model with heavy disk and network I/O. The platform > will be FreeBSD and Linux. Overall, we are seeking a C10K solution. > > > > I started reading through the libevent source and noticed several > comments about not being thread-safe. However, I have seen references > to other projects that are multi-threaded and use libevent. I need to > explore libevent and determine if it is viable for my project. Have > there been discussions on threading issues in the mailing list > archive? Is there another source of information on threads and > libevent? > > > > Thanks, > > Glen Hein > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070112/b47dc0bf/attachment.htm From dgotwisner at rosum.com Fri Jan 12 14:44:17 2007 From: dgotwisner at rosum.com (Dave Gotwisner) Date: Fri Jan 12 14:44:19 2007 Subject: [Libevent-users] Wanting to use msgrcv with Libevent Message-ID: <45A7E511.1080000@rosum.com> I have a series of programs that lend themselves to using message queues for communication between them. I am currently using libevent for these programs for network data and timers. I would rather not have to sit on a localhost tcp connection (the data received is variable length, based upon the message type) between the two tasks. I have looked through the mailling list archives and through the documentation, and I suspect the answer to my question is "no". Is there a way to register a message queue event and have Libevent issue a callback to a function that processes the message? I would also prefer not to have to set a timer and poll the message queue every second or so, although I can afford one second resolution for message reception. Thanks in advance, Dave From toby.douglass at summerblue.net Fri Jan 12 16:50:43 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Fri Jan 12 16:51:10 2007 Subject: [Libevent-users] IOCP In-Reply-To: <45A7E511.1080000@rosum.com> References: <45A7E511.1080000@rosum.com> Message-ID: <45A802B3.5030303@summerblue.net> Just a head's-up; I intend to finish the IOCP API and example application this weekend. Apologies for the intermission! :-) From toby.douglass at summerblue.net Mon Jan 15 07:07:54 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Mon Jan 15 07:08:13 2007 Subject: [Libevent-users] IOCP Message-ID: <22232.82.195.181.130.1168862874.squirrel@webmail.serve.com> My graphics card died Saturday afternoon, so I've not been able to finish the IOCP stuff. Next weekend, hopefully. From edchan at adobe.com Wed Jan 17 01:04:34 2007 From: edchan at adobe.com (Edward Chan) Date: Wed Jan 17 01:04:43 2007 Subject: [Libevent-users] is there an updated man page Message-ID: <06D3935708FAE242A5FDFB708B5F391E0261FF8F@namail4.corp.adobe.com> Or is this one the latest? http://monkey.org/~provos/libevent/event3.html Thanks, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070116/57ffa649/attachment.htm From provos at citi.umich.edu Thu Jan 18 01:29:11 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Jan 18 01:29:23 2007 Subject: [Libevent-users] [Patch] http server high port/getaddrinfo bug In-Reply-To: References: Message-ID: <850f7cbe0701172229u35c8c8b3x47c31873e0fc716d@mail.gmail.com> Thank you. Especially for the addition to the regression test. Both patches submitted to trunk. Niels. On 1/12/07, Philip Lewis wrote: > make_socket() in http.c takes the port as a short instead of an > unsigned short, so ports higher than 32767 become a negative number in > the string given to getaddrinfo(), which fails. > > Also, getaddrinfo() uses the return code instead of errno, so it fails > with "[warn] getaddrinfo: Success". getnameinfo() also returns errors > this way. > > Patch fixes both. > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > > From rafic at bezeqint.net Sun Jan 21 19:06:10 2007 From: rafic at bezeqint.net (Rafi Cohen) Date: Sun Jan 21 19:06:27 2007 Subject: [Libevent-users] implementing timers in a multithread application Message-ID: Hello, I'm new in this list and I apologize in advance if my questions are too basic. I'm writing an application which "talks" with a number of test devices connected to a gpib card and I'm using for this the open source linux gpib driver (http://linux-gpib.sourceforge.net). This is a multithread application, each thread for each device as each device has it's own device descriptor to read from and write to it. Within various states of the state machine of each thread, I need to implement a look, sending a query to the device for it's current state and reading the response. The loop may end in 2 ways: either the device has transitioned to a new state or timeout has occured and no transition happened during this time. Those timers are my problem here. The timers may vary within a thread, depending on the expected state and, each thread has to have it's own timers independent of the other threads. I cannot implement this by using alarm, setitimer and getitimer as they are process wide and not thread safe. So I wonder if libevent may be the appropriate tool to help me implement those timers. If indeed, then how should I use it and which functions are relevant for this case? I'll continue to investigate this by myself, but any assistance I can get from the list members will be most appreciated. Thanks in advance, and sorry for the lengthy and detailed message. Regards, Rafi. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070122/a7856c8d/attachment.htm From william at 25thandClement.com Sun Jan 21 20:10:40 2007 From: william at 25thandClement.com (William Ahern) Date: Sun Jan 21 20:10:46 2007 Subject: [Libevent-users] implementing timers in a multithread application In-Reply-To: References: Message-ID: <20070122011040.GA21066@wilbur.25thandClement.com> On Mon, Jan 22, 2007 at 02:06:10AM +0200, Rafi Cohen wrote: > Hello, I'm new in this list and I apologize in advance if my questions > are too basic. > I'm writing an application which "talks" with a number of test devices > connected to a gpib card and I'm using for this the open source linux > gpib driver (http://linux-gpib.sourceforge.net). > This is a multithread application, each thread for each device as each > device has it's own device descriptor to read from and write to it. > Within various states of the state machine of each thread, I need to > implement a look, sending a query to the device for it's current state > and reading the response. > The loop may end in 2 ways: either the device has transitioned to a new > state or timeout has occured and no transition happened during this > time. > Those timers are my problem here. The timers may vary within a thread, > depending on the expected state and, each thread has to have it's own > timers independent of the other threads. > I cannot implement this by using alarm, setitimer and getitimer as they > are process wide and not thread safe. > So I wonder if libevent may be the appropriate tool to help me implement > those timers. It sounds like libevent is not what you need. For libevent to even be an option in your scenario, your device descriptors must be pollable and capable of operating in non-blocking mode. But, if they're pollable that begs the question of why you're using an asynchronous alarm. Assuming you require the asynchronous alarm/timer, why not do it yourself? You only need one timer for the entire process. For example, install a timer with an interval which is the minimum precision you would need to service a timeout for any blocking operation in any of your threads. Block that interval timer's signal in all threads but the alarm multiplexing thread. Then, manually call pthread_kill()--from the multiplexing thread--for each thread which requested a timeout. Using, of course, a different, non-blocked signal number so the other threads can receive it. Of course, the implementation isn't trivial. Dealing with signals alone, or threads alone, is difficult enough. Running a libevent loop in the multiplexing thread in order to take advantage of the signal synchronizing behavior (libevent sends signals down a pipe(2) so they can be dealt with more safely) might be an option. From wilmer at gaast.net Mon Jan 22 12:00:31 2007 From: wilmer at gaast.net (Wilmer van der Gaast) Date: Mon Jan 22 12:01:07 2007 Subject: [Libevent-users] fork() causes problems Message-ID: <45B4EDAF.6090404@gaast.net> Hello, I'm getting very strange behaviour from libevent (when using it with epoll()). My program (BitlBee in ForkDaemon mode) has a master process which accepts clients and creates a new child process for every connection. When using select() or poll() for event handling, this works perfectly. However, when using epoll() (which is the whole reason I started using libevent, GLib can do event handling with poll()/select() already) things go wrong once there's more than one client. With only one client everything works perfectly, but once there's another one, process 1 seems to get the other process' event notifications. (Process 2 does get the notifications too, BTW.) Process 1 then tries to read from the socket, gets EAGAIN and panics because it obviously doesn't expect to get such an error in a "there's data, read it" event handler. Most likely this behaviour comes from the fact that all processes share one epoll fd, which is hardly ever a good idea. See this post: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.0/0300.html So now I'm wondering, how do I make sure every process gets its own epfd? I found epoll_base_free(), but it's probably not what I'm looking for, because of this line: assert(TAILQ_EMPTY(&base->eventqueue)); This means that I have to remove all event handlers to make this function call successful, right? I really shouldn't do that, because most likely doing that will remove the event handler in the parent process too!!! (See the rest of the thread above.) So, does anybody know what to do to make this work properly? Wilmer van der Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://monkeymail.org/archives/libevent-users/attachments/20070122/165d1102/signature.bin From acd at weirdness.net Mon Jan 22 12:48:45 2007 From: acd at weirdness.net (Andrew Danforth) Date: Mon Jan 22 12:48:53 2007 Subject: [Libevent-users] fork() causes problems In-Reply-To: <45B4EDAF.6090404@gaast.net> References: <45B4EDAF.6090404@gaast.net> Message-ID: You could call event_init immediately after you fork in a child to get a fresh libevent instance. event_init returns a pointer to the event_base for the new instance which you must store and associate with all future events you plan to register. When registering a new event you must first set the appropriate base with event_base_set. The last time I looked, the most recently created event_base is assumed when a specific base is not provided, but I would not rely on that behavior. This approach is based upon my understanding of how libevent works internally, I've never actually used it with epoll on Linux, only devpoll on Solaris which is similar. If it works, your children will inherit the parent's epoll fd but just ignore it. Not sure if that's the behavior you'd like. I'm also a bit curious why you're using libevent in the first place if the architecture of your app is such that it forks for each client. libevent, and event based programming in general, allow you to service multiple clients from the same process quite easily. Andrew On 1/22/07, Wilmer van der Gaast wrote: > > Hello, > > I'm getting very strange behaviour from libevent (when using it with > epoll()). My program (BitlBee in ForkDaemon mode) has a master process > which accepts clients and creates a new child process for every > connection. When using select() or poll() for event handling, this works > perfectly. However, when using epoll() (which is the whole reason I > started using libevent, GLib can do event handling with poll()/select() > already) things go wrong once there's more than one client. > > With only one client everything works perfectly, but once there's > another one, process 1 seems to get the other process' event > notifications. (Process 2 does get the notifications too, BTW.) Process > 1 then tries to read from the socket, gets EAGAIN and panics because it > obviously doesn't expect to get such an error in a "there's data, read > it" event handler. > > Most likely this behaviour comes from the fact that all processes share > one epoll fd, which is hardly ever a good idea. See this post: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0403.0/0300.html > > So now I'm wondering, how do I make sure every process gets its own > epfd? I found epoll_base_free(), but it's probably not what I'm looking > for, because of this line: > > assert(TAILQ_EMPTY(&base->eventqueue)); > > This means that I have to remove all event handlers to make this > function call successful, right? I really shouldn't do that, because > most likely doing that will remove the event handler in the parent > process too!!! (See the rest of the thread above.) > > So, does anybody know what to do to make this work properly? > > > Wilmer van der Gaast. > > -- > +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ > | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | > | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | > +--- -- - ` ---------------+ +------ ----- ---- --- -- - + > > > > > > _______________________________________________ > 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/20070122/608fee98/attachment.htm From wilmer at gaast.net Mon Jan 22 19:07:53 2007 From: wilmer at gaast.net (Wilmer van der Gaast) Date: Mon Jan 22 19:08:08 2007 Subject: [Libevent-users] fork() causes problems In-Reply-To: References: <45B4EDAF.6090404@gaast.net> Message-ID: <45B551D9.8050109@gaast.net> Hello, Thanks for the quick answer! Andrew Danforth wrote: > You could call event_init immediately after you fork in a child to get a > fresh libevent instance. Hmm. That's what I tried immediately, but it didn't work very well. I'll give it another shot. Is this supposed to work in older versions of libevent too? > If it works, your children will > inherit the parent's epoll fd but just ignore it. Not sure if that's > the behavior you'd like. Well, it's acceptable. Cleaning up everything would be nicer, of course... > libevent, and event based programming in > general, allow you to service multiple clients from the same process > quite easily. > It can do that. But borrowing code from Gaim 0.58 doesn't make it that easy. ;-) BitlBee can do everything in one process, but when serving tens of clients, it's a matter of time before some critical bug kills the program and a whole bunch of connections. We're working on stability improvements, but we're not quite there yet. Wilmer van der Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://monkeymail.org/archives/libevent-users/attachments/20070123/8844831b/signature-0001.bin From nickm at freehaven.net Tue Jan 23 15:22:48 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Jan 23 15:23:02 2007 Subject: [Libevent-users] [Re-sent] [Patch] Reformatted, updated evdns.c patches. Message-ID: <20070123202248.GD3325@totoro.wangafu.net> [My apologies if anybody gets a duplicate copy of this. My original message was too long, has been "pending moderator approval" since Sunday. I've tried to follow the link to cancel it, but monkeymail.org doesn't seem to be answering HTTP requests. So, I'm sending the original email _sans_ attachments, and putting the actual patches up on the web for download.] Hi, Niels! This is a reformatted, corrected, updated, and expanded version of my patch from December 15 to add server and IPv6 support to evdns. This time I've broken it down into multiple parts; this may help some. Alas, the passage of time has added more code: hopefully this time it will be easier to follow. :) These patches need to be applied in order; they have dependencies. 01_ipv6.diff Adds support for forward and reverse IPv6 queries with two new functions: evdns_resolve_ipv6() and evdns_resolve_reverse_ipv6() 02_misc.diff Fixes numerous small issues: - Fixes spelling: choaked -> choked - Make error strings static - The MS_WINDOWS macro is a Tor-ism; use WIN32 consistently. - Have the GET32/16/8 macros "goto err" instead of "return -1"; this gets used in patch 05 below. - Detect misaligned A and AAAA replies. - Avoid compiler warnings about unused variables. - Always use snprintf instead of sprintf: this keeps the OpenBSD linker from complaining. - Fix compiler warning about running off the end of a non-void function. - Fix compiler warning about mismatch between the type of st_size and size_t. - Add missing argument list to evdns_init(). - Add missing argument to logfn. 03_name_compression.diff This patch adds code to implement name compression via a table-based lookup system. The implementation isn't so efficient, but it can be replaced easily if it turns out not to be critical path. This code is used in patch 05 below; it isn't activated for sending requests, since we never send more than one name per request. 04_options.diff 04b_options_oops.diff (I messed up the original version of this patch; apply both 04 and 04b in succession in order to get the right code.) This patch adds a function to set some options (timeout, attempts) via the API and override the settings in the resolv.conf file. It also provides a way to set some other global configuration values (max-timeouts, max-inflight). It keeps the nameservers from being modified when DNS_OPTION_NAMESERVER isn't set. Finally, it makes resolv_conf_parse() give an error code if we're parsing nameservers and we don't find any. 05_server.diff This patch adds DNS server support to evdns.c. It provides an external API for clients to register a dns server socket, and a callback that will learn about DNS requests. After examining the request, the caller should eventually drop it by calling evdns_server_request_drop() or add answers with evdns_Server_request_add_*_reply() and send the final result with evdns_server_request_respond(). To avoid limits on attachment sizes, I'm putting these patches on the web at: http://freehaven.net/~nickm/libevent_server_patch/ If you've got a chance to check them out, please let me know what you think. many thanks, -- 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/20070123/84216843/attachment.bin From sq at sqstudio.ru Wed Jan 24 12:56:10 2007 From: sq at sqstudio.ru (Dmitry Lohansky) Date: Wed Jan 24 13:54:35 2007 Subject: [Libevent-users] http-client fix Message-ID: <03964816.20070124205610@sqstudio.ru> Good time of day! I found bug when I tryed to use outgoing http requests for getting some data from remote servers (image/jpeg in my case). I think that evcon->input_buffer must be copied to req->input_buffer, before reading other data to req->input_buffer. (I'm sorry if this is not new, i'm newby in this list) There is a patch: --- ./http.c.orig Sun Dec 3 00:30:04 2006 +++ ./http.c Wed Jan 24 20:37:27 2007 @@ -554,9 +555,6 @@ } } - /* hand what ever we read over to the request */ - evbuffer_add_buffer(req->input_buffer, evcon->input_buffer); - /* notify the user of the request */ (*req->cb)(req, req->cb_arg); @@ -1063,8 +1061,11 @@ __func__, req->ntoread, EVBUFFER_LENGTH(evcon->input_buffer))); - if (req->ntoread > 0) + if (req->ntoread > 0) { + /* hand what ever we read over to the request */ + evbuffer_add_buffer(req->input_buffer, evcon->input_buffer); req->ntoread -= EVBUFFER_LENGTH(evcon->input_buffer); + } if (req->ntoread == 0) { evhttp_connection_done(evcon); -- W/ best regards, Dmitry From toby.douglass at summerblue.net Thu Jan 25 04:22:08 2007 From: toby.douglass at summerblue.net (Toby Douglass) Date: Thu Jan 25 04:22:25 2007 Subject: [Libevent-users] IOCP update In-Reply-To: <03964816.20070124205610@sqstudio.ru> References: <03964816.20070124205610@sqstudio.ru> Message-ID: <33673.82.195.181.130.1169716928.squirrel@webmail.serve.com> Sorry for the delay. My PC power supply has died. Replacement being ordered tomorrow. From oz at nixil.net Thu Jan 25 15:28:45 2007 From: oz at nixil.net (Phil Oleson) Date: Thu Jan 25 15:29:10 2007 Subject: [Libevent-users] fixes for mem leaks etc Message-ID: <45B912FD.4030300@nixil.net> Niels, My company recently licensed Coverity Prevent for internal use, and since we used libevent in at least 1-2 apps, I thought I'd check out libevent. It found a couple memory leaks in http.c and evrpc.c, and a possible FORWARD_NULL issue (which I fixed, though it's debatable if it would actually ever pop up). I've also included the C++ fix to evdns.h as it's not been commited to Subversion yet. Patches attached. -Phil. -------------- next part -------------- Index: evdns.h =================================================================== --- evdns.h (revision 312) +++ evdns.h (working copy) @@ -237,6 +237,10 @@ #ifndef EVENTDNS_H #define EVENTDNS_H +#ifdef __cplusplus +extern "C" { +#endif + /* Error codes 0-5 are as described in RFC 1035. */ #define DNS_ERR_NONE 0 /* The name server was unable to interpret the query */ @@ -303,4 +307,8 @@ #define DNS_NO_SEARCH 1 +#ifdef __cplusplus +} +#endif + #endif // !EVENTDNS_H -------------- next part -------------- Index: event.c =================================================================== --- event.c (revision 312) +++ event.c (working copy) @@ -301,6 +301,8 @@ } } + if (!activeq) return; + for (ev = TAILQ_FIRST(activeq); ev; ev = TAILQ_FIRST(activeq)) { event_queue_remove(base, ev, EVLIST_ACTIVE); -------------- next part -------------- Index: evrpc.c =================================================================== --- evrpc.c (revision 312) +++ evrpc.c (working copy) @@ -260,19 +260,25 @@ void evrpc_pool_free(struct evrpc_pool *pool) { - struct evhttp_connection *connection; - struct evrpc_request_wrapper *request; + struct evhttp_connection *connection, *conn_next; + struct evrpc_request_wrapper *request, *req_next; - while ((request = TAILQ_FIRST(&pool->requests)) != NULL) { - TAILQ_REMOVE(&pool->requests, request, next); + request = TAILQ_FIRST(&pool->requests); + while (request != NULL) { + req_next = TAILQ_NEXT(request, next); /* if this gets more complicated we need our own function */ evrpc_request_wrapper_free(request); + request = req_next; } + TAILQ_INIT(&pool->requests); - while ((connection = TAILQ_FIRST(&pool->connections)) != NULL) { - TAILQ_REMOVE(&pool->connections, connection, next); + connection = TAILQ_FIRST(&pool->connections); + while (connection != NULL) { + conn_next = TAILQ_NEXT(connection, next); evhttp_connection_free(connection); + connection = conn_next; } + TAILQ_INIT(&pool->connections); free(pool); } -------------- next part -------------- Index: http.c =================================================================== --- http.c (revision 312) +++ http.c (working copy) @@ -715,7 +715,7 @@ void evhttp_connection_free(struct evhttp_connection *evcon) { - struct evhttp_request *req; + struct evhttp_request *req, *next_req; /* notify interested parties that this connection is going down */ if (evcon->fd != -1) { @@ -724,10 +724,13 @@ } /* remove all requests that might be queued on this connection */ - while ((req = TAILQ_FIRST(&evcon->requests)) != NULL) { - TAILQ_REMOVE(&evcon->requests, req, next); + req = TAILQ_FIRST(&evcon->requests); + while (req != NULL) { + next_req = TAILQ_NEXT(req, next); evhttp_request_free(req); + req = next_req; } + TAILQ_INIT(&evcon->requests); if (evcon->http_server != NULL) { struct evhttp *http = evcon->http_server; @@ -1021,16 +1024,17 @@ void evhttp_clear_headers(struct evkeyvalq *headers) { - struct evkeyval *header; + struct evkeyval *header, *next_head; - for (header = TAILQ_FIRST(headers); - header != NULL; - header = TAILQ_FIRST(headers)) { - TAILQ_REMOVE(headers, header, next); + header = TAILQ_FIRST(headers); + while (header != NULL) { + next_head = TAILQ_NEXT(header, next); free(header->key); free(header->value); free(header); + header = next_head; } + TAILQ_INIT(headers); } /* @@ -1863,25 +1867,30 @@ void evhttp_free(struct evhttp* http) { - struct evhttp_cb *http_cb; - struct evhttp_connection *evcon; + struct evhttp_cb *http_cb, *cb_next; + struct evhttp_connection *evcon, *evcon_next; int fd = http->bind_ev.ev_fd; /* Remove the accepting part */ event_del(&http->bind_ev); close(fd); - while ((evcon = TAILQ_FIRST(&http->connections)) != NULL) { - /* evhttp_connection_free removes the connection */ - evhttp_connection_free(evcon); + evcon = TAILQ_FIRST(&http->connections); + while (evcon != NULL) { + evcon_next = TAILQ_NEXT(evcon, next); + evhttp_connection_free(evcon); /* removes the connection */ + evcon = evcon_next; } - while ((http_cb = TAILQ_FIRST(&http->callbacks)) != NULL) { - TAILQ_REMOVE(&http->callbacks, http_cb, next); + http_cb = TAILQ_FIRST(&http->callbacks); + while (http_cb != NULL) { + cb_next = TAILQ_NEXT(http_cb, next); free(http_cb->what); free(http_cb); + http_cb = cb_next; } - + TAILQ_INIT(&http->callbacks); + free(http); } From glen at llnw.com Thu Jan 25 21:16:49 2007 From: glen at llnw.com (Glen Hein) Date: Thu Jan 25 21:17:06 2007 Subject: [Libevent-users] assertion in event_base_free Message-ID: <006b01c740f0$09909ef0$6401a8c0@GHDualLaptop> Hello, I'm writing a client/server to study libevent and I'm getting this assertion when I try to free the base. event.c:220: event_base_free: Assertion `(((&base->eventqueue)->tqh_first) == ((void *)0))' failed. My test is rather simple, I read one line of text from the client and then I close the connection. Only one read event is fired. I don't know why I'm getting the assertion. Can anyone help? Thanks, Glen Hein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070125/60607e0e/attachment.htm From yoonghm at gmail.com Fri Jan 26 00:16:58 2007 From: yoonghm at gmail.com (Hor Meng Yoong) Date: Fri Jan 26 00:17:01 2007 Subject: [Libevent-users] Compile on Windows 2000 Message-ID: <27726d480701252116t625e11cv75dd253c66569984@mail.gmail.com> Hi: Just downloaded libevent 1.2a from the web. I opened the file WIN32-Prj\libevent.dsw but there is no project in it. Any idea how to fix it? Regards Yoong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070126/74269df1/attachment.htm From yoonghm at gmail.com Fri Jan 26 00:49:50 2007 From: yoonghm at gmail.com (Hor Meng Yoong) Date: Fri Jan 26 00:49:56 2007 Subject: [Libevent-users] struct addrinfo is missing in cygwin's /usr/include/netdb.h Message-ID: <27726d480701252149n489046e1rb978c76a1476f9ab@mail.gmail.com> Hi: I tried to compile libevent-1.2a on cygwin. The structure addrinfo is not defined in /usr/include/netdb.h. Anyone has a fix for this? Regards Yoong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070126/6b4e6847/attachment-0001.htm From yoonghm at gmail.com Fri Jan 26 01:01:36 2007 From: yoonghm at gmail.com (Hor Meng Yoong) Date: Fri Jan 26 01:01:39 2007 Subject: [Libevent-users] Build libevent-1.2a on cygwin Message-ID: <27726d480701252201n39ec9122t2c31e5fe117afe0f@mail.gmail.com> Hi: I faced problem compiling libevent-1.2a on cygwin. Mainly cygwin's header for struct addrinfo and getaddrinfo(), etc are not in the standard /usr/include but in /usr/include/w32api/. As I do not know configure, anyone has fixed it? Regards Yoong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070126/42750efd/attachment.htm From oz at nixil.net Fri Jan 26 01:39:42 2007 From: oz at nixil.net (Phil Oleson) Date: Fri Jan 26 01:39:48 2007 Subject: [Libevent-users] Build libevent-1.2a on cygwin In-Reply-To: <27726d480701252201n39ec9122t2c31e5fe117afe0f@mail.gmail.com> References: <27726d480701252201n39ec9122t2c31e5fe117afe0f@mail.gmail.com> Message-ID: <45B9A22E.4050804@nixil.net> Hor Meng Yoong wrote: > Hi: > > I faced problem compiling libevent-1.2a on cygwin. Mainly cygwin's > header for struct addrinfo and getaddrinfo(), etc are not in the > standard /usr/include but in /usr/include/w32api/. As I do not know > configure, anyone has fixed it? Try something like: env CFLAGS=-I/usr/include/w32api ./configure <..your other args here..> good luck. -Phil. From oz at nixil.net Fri Jan 26 01:46:42 2007 From: oz at nixil.net (Phil Oleson) Date: Fri Jan 26 01:46:49 2007 Subject: [Libevent-users] two more patches (from the FreeBSD port) Message-ID: <45B9A3D2.50802@nixil.net> I found these two patches in the freebsd port. They are for compatibility with older compilers. I've upgraded my home system so I'm not noticing these issues. -Phil. -------------- next part -------------- # # Define va_copy if not exists. 4.x for exemple. # --- buffer.c.orig Mon Dec 4 11:34:31 2006 +++ buffer.c Mon Dec 4 11:35:44 2006 @@ -138,6 +138,9 @@ buffer = (char *)buf->buffer + buf->off; space = buf->totallen - buf->misalign - buf->off; +#ifndef va_copy +#define va_copy(dest,src) memcpy(&dest, &src, sizeof (va_list)) +#endif va_copy(aq, ap); #ifdef WIN32 -------------- next part -------------- # # Fix build with old gcc # --- http.c.orig Sat Dec 2 19:30:04 2006 +++ http.c Mon Dec 4 11:17:38 2006 @@ -518,6 +518,7 @@ evhttp_connection_done(struct evhttp_connection *evcon) { struct evhttp_request *req = TAILQ_FIRST(&evcon->requests); + int need_close; /* * if this is an incoming connection, we need to leave the request @@ -527,7 +528,7 @@ TAILQ_REMOVE(&evcon->requests, req, next); req->evcon = NULL; - int need_close = + need_close = evhttp_is_connection_close(req->input_headers) || evhttp_is_connection_close(req->output_headers); From william at 25thandClement.com Fri Jan 26 15:29:28 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Jan 26 15:29:58 2007 Subject: [Libevent-users] struct addrinfo is missing in cygwin's /usr/include/netdb.h In-Reply-To: <27726d480701252149n489046e1rb978c76a1476f9ab@mail.gmail.com> References: <27726d480701252149n489046e1rb978c76a1476f9ab@mail.gmail.com> Message-ID: <20070126202928.GA5633@wilbur.25thandClement.com> On Fri, Jan 26, 2007 at 01:49:50PM +0800, Hor Meng Yoong wrote: > Hi: > > I tried to compile libevent-1.2a on cygwin. The structure addrinfo is not > defined in /usr/include/netdb.h. > Anyone has a fix for this? > Cygwin hasn't added it yet. You might try grabbing the portable version from the OpenSSH sources. From william at 25thandClement.com Fri Jan 26 15:30:54 2007 From: william at 25thandClement.com (William Ahern) Date: Fri Jan 26 15:30:58 2007 Subject: [Libevent-users] Build libevent-1.2a on cygwin In-Reply-To: <27726d480701252201n39ec9122t2c31e5fe117afe0f@mail.gmail.com> References: <27726d480701252201n39ec9122t2c31e5fe117afe0f@mail.gmail.com> Message-ID: <20070126203054.GB5633@wilbur.25thandClement.com> On Fri, Jan 26, 2007 at 02:01:36PM +0800, Hor Meng Yoong wrote: > Hi: > > I faced problem compiling libevent-1.2a on cygwin. Mainly cygwin's header > for struct addrinfo and getaddrinfo(), etc are not in the standard > /usr/include but in /usr/include/w32api/. As I do not know configure, anyone > has fixed it? > This is a bit misleading. w32api has some definitions, but many version of Windows (e.g. my version of XP), won't link properly. There's more information on the MSDN website. From luca at integratech.dyndns.org Fri Jan 26 16:31:33 2007 From: luca at integratech.dyndns.org (Leandro Lucarella) Date: Fri Jan 26 16:31:51 2007 Subject: [Libevent-users] eventxx 0.1 released Message-ID: <45BA7335.1060906@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. It's designed to be as close to use to libevent (without compromising modern C++ programming techniques) and efficiency (since all implementation is trivial and inline, theoretically, it imposes no overhead at all). 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. [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 provos at citi.umich.edu Fri Jan 26 23:05:29 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri Jan 26 23:05:33 2007 Subject: [Libevent-users] fixes for mem leaks etc In-Reply-To: <45B912FD.4030300@nixil.net> References: <45B912FD.4030300@nixil.net> Message-ID: <850f7cbe0701262005u62bdb904q6bf65d7d6c0ec9aa@mail.gmail.com> Hi Phil, the C++ extern change is made. I also asserted activeq in event.c. The tailq related changes are unnecessary. If Coverity flagged them then they are false positives. Thanks for the patches, Niels. On 1/25/07, Phil Oleson wrote: > Index: evdns.h > =================================================================== > --- evdns.h (revision 312) > +++ evdns.h (working copy) > @@ -237,6 +237,10 @@ > #ifndef EVENTDNS_H > #define EVENTDNS_H > > +#ifdef __cplusplus > +extern "C" { > +#endif > + > /* Error codes 0-5 are as described in RFC 1035. */ > #define DNS_ERR_NONE 0 > /* The name server was unable to interpret the query */ > @@ -303,4 +307,8 @@ > > #define DNS_NO_SEARCH 1 > > +#ifdef __cplusplus > +} > +#endif > + > #endif // !EVENTDNS_H > > > Index: event.c > =================================================================== > --- event.c (revision 312) > +++ event.c (working copy) > @@ -301,6 +301,8 @@ > } > } > > + if (!activeq) return; > + > for (ev = TAILQ_FIRST(activeq); ev; ev = TAILQ_FIRST(activeq)) { > event_queue_remove(base, ev, EVLIST_ACTIVE); > > > > Index: evrpc.c > =================================================================== > --- evrpc.c (revision 312) > +++ evrpc.c (working copy) > @@ -260,19 +260,25 @@ > void > evrpc_pool_free(struct evrpc_pool *pool) > { > - struct evhttp_connection *connection; > - struct evrpc_request_wrapper *request; > + struct evhttp_connection *connection, *conn_next; > + struct evrpc_request_wrapper *request, *req_next; > > - while ((request = TAILQ_FIRST(&pool->requests)) != NULL) { > - TAILQ_REMOVE(&pool->requests, request, next); > + request = TAILQ_FIRST(&pool->requests); > + while (request != NULL) { > + req_next = TAILQ_NEXT(request, next); > /* if this gets more complicated we need our own function */ > evrpc_request_wrapper_free(request); > + request = req_next; > } > + TAILQ_INIT(&pool->requests); > > - while ((connection = TAILQ_FIRST(&pool->connections)) != NULL) { > - TAILQ_REMOVE(&pool->connections, connection, next); > + connection = TAILQ_FIRST(&pool->connections); > + while (connection != NULL) { > + conn_next = TAILQ_NEXT(connection, next); > evhttp_connection_free(connection); > + connection = conn_next; > } > + TAILQ_INIT(&pool->connections); > > free(pool); > } > > > Index: http.c > =================================================================== > --- http.c (revision 312) > +++ http.c (working copy) > @@ -715,7 +715,7 @@ > void > evhttp_connection_free(struct evhttp_connection *evcon) > { > - struct evhttp_request *req; > + struct evhttp_request *req, *next_req; > > /* notify interested parties that this connection is going down */ > if (evcon->fd != -1) { > @@ -724,10 +724,13 @@ > } > > /* remove all requests that might be queued on this connection */ > - while ((req = TAILQ_FIRST(&evcon->requests)) != NULL) { > - TAILQ_REMOVE(&evcon->requests, req, next); > + req = TAILQ_FIRST(&evcon->requests); > + while (req != NULL) { > + next_req = TAILQ_NEXT(req, next); > evhttp_request_free(req); > + req = next_req; > } > + TAILQ_INIT(&evcon->requests); > > if (evcon->http_server != NULL) { > struct evhttp *http = evcon->http_server; > @@ -1021,16 +1024,17 @@ > void > evhttp_clear_headers(struct evkeyvalq *headers) > { > - struct evkeyval *header; > + struct evkeyval *header, *next_head; > > - for (header = TAILQ_FIRST(headers); > - header != NULL; > - header = TAILQ_FIRST(headers)) { > - TAILQ_REMOVE(headers, header, next); > + header = TAILQ_FIRST(headers); > + while (header != NULL) { > + next_head = TAILQ_NEXT(header, next); > free(header->key); > free(header->value); > free(header); > + header = next_head; > } > + TAILQ_INIT(headers); > } > > /* > @@ -1863,25 +1867,30 @@ > void > evhttp_free(struct evhttp* http) > { > - struct evhttp_cb *http_cb; > - struct evhttp_connection *evcon; > + struct evhttp_cb *http_cb, *cb_next; > + struct evhttp_connection *evcon, *evcon_next; > int fd = http->bind_ev.ev_fd; > > /* Remove the accepting part */ > event_del(&http->bind_ev); > close(fd); > > - while ((evcon = TAILQ_FIRST(&http->connections)) != NULL) { > - /* evhttp_connection_free removes the connection */ > - evhttp_connection_free(evcon); > + evcon = TAILQ_FIRST(&http->connections); > + while (evcon != NULL) { > + evcon_next = TAILQ_NEXT(evcon, next); > + evhttp_connection_free(evcon); /* removes the connection */ > + evcon = evcon_next; > } > > - while ((http_cb = TAILQ_FIRST(&http->callbacks)) != NULL) { > - TAILQ_REMOVE(&http->callbacks, http_cb, next); > + http_cb = TAILQ_FIRST(&http->callbacks); > + while (http_cb != NULL) { > + cb_next = TAILQ_NEXT(http_cb, next); > free(http_cb->what); > free(http_cb); > + http_cb = cb_next; > } > - > + TAILQ_INIT(&http->callbacks); > + > free(http); > } > > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > From nickm at freehaven.net Sat Jan 27 00:06:44 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Sat Jan 27 00:06:57 2007 Subject: [Libevent-users] [Patch] Add a regression test for DNS IPv6 records; fix two bugs in the AAAA record code. Message-ID: <20070127050644.GP22997@totoro.wangafu.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070127/ff68cd9c/attachment-0001.bin From provos at citi.umich.edu Sat Jan 27 03:39:21 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat Jan 27 03:39:29 2007 Subject: [Libevent-users] Re: [Patch] Add a regression test for DNS IPv6 records; fix two bugs in the AAAA record code. In-Reply-To: <20070127050644.GP22997@totoro.wangafu.net> References: <20070127050644.GP22997@totoro.wangafu.net> Message-ID: <850f7cbe0701270039t63d3ff53j5248b0f7b46cc160@mail.gmail.com> Hah. That was super quick. Thank you very much. The patch has been submitted to trunk. Niels. On 1/26/07, Nick Mathewson wrote: > So, I saw that Niels had checked in my code to do IPv6 DNS lookups > with the comment: > AAAA support for DNS; from Nick Mathewson. > > unfortunately, no regression test > > "Oh dear!" I thought. "I'd better write a regression test, just to > prove that my code works." > > Turns out, it had a couple of bugs. This patch fixes those bugs, and > adds a regression test. It also fixes a small bug in the IPv4 DNS > regression test, which would, if it received N A records, print the > first record N times. > > many thanks, and apologies for the bugs, > -- > Nick Mathewson > > > From nickm at freehaven.net Mon Jan 29 13:08:04 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Jan 29 13:08:30 2007 Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS servers to evdns.c (This time with regression tests!) Message-ID: <20070129180804.GY22997@totoro.wangafu.net> Hello again, and thank you for your patience. This the latest version of my patch to add DNS server support to evdns.c. This time it incorporates regression tests. While writing the tests, it proved necessary to extend evdns_nameserver_ip_add to allow an IP:port syntax. The tests also turned up a bug in evdns_resolve_reverse, where the correct TTL would never be sent to the callback; this patch also fixes that bug. Summary: This patch adds DNS server support to evdns.c. It provides an external API for clients to register a dns server socket, and a callback that will learn about DNS requests. After examining the request, the caller should eventually drop it by calling evdns_server_request_drop() or add answers with evdns_Server_request_add_*_reply() and send the final result with evdns_server_request_respond(). Extend evdns_nameserver_ip_add() to accept IP:Port syntax for nameservers running on ports other than 53. Fix handling of TTLs in reverse lookups. This is a pretty big patch (~30K), so I'm not going to attach it here; you can download it at: http://freehaven.net/~nickm/libevent_server_patch/dns_server_v3.diff 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/20070129/367ecb06/attachment.bin From nickm at freehaven.net Mon Jan 29 16:24:49 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Jan 29 16:26:24 2007 Subject: [Libevent-users] [Patch] Fix http.c on mingw, again Message-ID: <20070129212449.GC22997@totoro.wangafu.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070129/da00be0b/attachment.bin From wouter at NLnetLabs.nl Tue Jan 30 07:20:29 2007 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Tue Jan 30 07:55:46 2007 Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS servers to evdns.c (This time with regression tests!) In-Reply-To: <20070129180804.GY22997@totoro.wangafu.net> References: <20070129180804.GY22997@totoro.wangafu.net> Message-ID: <45BF380D.9030307@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Mathewson wrote: > Hello again, and thank you for your patience. This the latest version > of my patch to add DNS server support to evdns.c. This time it > incorporates regression tests. While writing the tests, it proved > necessary to extend evdns_nameserver_ip_add to allow an IP:port > syntax. The tests also turned up a bug in evdns_resolve_reverse, > where the correct TTL would never be sent to the callback; this patch > also fixes that bug. > > Summary: > This patch adds DNS server support to evdns.c. It provides an > external API for clients to register a dns server socket, and a > callback that will learn about DNS requests. After examining the > request, the caller should eventually drop it by calling > evdns_server_request_drop() or add answers with > evdns_Server_request_add_*_reply() and send the final result with > evdns_server_request_respond(). > > Extend evdns_nameserver_ip_add() to accept IP:Port syntax for > nameservers running on ports other than 53. > > Fix handling of TTLs in reverse lookups. > 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? Trying to promote simple and clean, Wouter Wijngaards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFvzgNkDLqNwOhpPgRAjgpAJ90lv0Xsj9djhNGd4x88ApOqD7Y+ACeNruT PnjjwQAIgwdOWNC+L/hcHSQ= =OMrE -----END PGP SIGNATURE-----