From C.Rzewuski at elka.pw.edu.pl Wed Apr 2 16:15:59 2008 From: C.Rzewuski at elka.pw.edu.pl (Cezary Rzewuski) Date: Wed Apr 2 16:22:59 2008 Subject: [Libevent-users] http: libevent vs many threads Message-ID: <47F3E97F.3010400@elka.pw.edu.pl> Hi, I'd like to ask if sending http requests with libevent is carried out in separate thread or is the library single-threaded? I want to use the library in a program which will visit many URL and download it's content. Is it good idea to use libevent or the classic solution with creating a separate thread per URL request will be much more efficient solution? I saw that libevent was used in spybye, which is kind of similar what I want to do. I was wondering if spybye were more efficient with requests served in separate threads instead of using libevent (I don't say that it's not efficient, just theoretically). Kind regards, Cezary From coroberti at gmail.com Thu Apr 3 00:25:21 2008 From: coroberti at gmail.com (Robert Iakobashvili) Date: Thu Apr 3 00:25:24 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <47F3E97F.3010400@elka.pw.edu.pl> References: <47F3E97F.3010400@elka.pw.edu.pl> Message-ID: <7e63f56c0804022125s209ac9c8h5fbdff4b9d3a8bda@mail.gmail.com> Hi Cezary, On Wed, Apr 2, 2008 at 11:15 PM, Cezary Rzewuski wrote: > Hi, > I'd like to ask if sending http requests with libevent is carried out in > separate thread or is the library > single-threaded? I want to use the library in a program which will visit > many URL and download > it's content. Is it good idea to use libevent or the classic solution with > creating a separate thread per URL > request will be much more efficient solution? > > I saw that libevent was used in spybye, which is kind of similar what I > want to do. I was wondering > if spybye were more efficient with requests served in separate threads > instead of using libevent > (I don't say that it's not efficient, just theoretically). > > Kind regards, > Cezary > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > If you are doing a heavy load server on a HW with multiple cores and/or multiple CPUs, you indeed have a business case for threading. Y may wish to look at ACE-library implementation of Leader-Followers design pattern. There are also great folks on the list, that implemented the pattern using libevent; look in the mailing archives. -- Sincerely, Robert Iakobashvili "Light will come from Jerusalem" ........................................................... http://curl-loader.sourceforge.net An open-source web testing and traffic generation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20080403/0da77fc3/attachment.htm From william at 25thandClement.com Thu Apr 3 01:04:39 2008 From: william at 25thandClement.com (William Ahern) Date: Thu Apr 3 01:07:39 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <47F3E97F.3010400@elka.pw.edu.pl> References: <47F3E97F.3010400@elka.pw.edu.pl> Message-ID: <20080403050439.GB883@wilbur.25thandClement.com> On Wed, Apr 02, 2008 at 10:15:59PM +0200, Cezary Rzewuski wrote: > Hi, > I'd like to ask if sending http requests with libevent is carried out in > separate thread or is the library > single-threaded? I want to use the library in a program which will visit > many URL and download > it's content. Is it good idea to use libevent or the classic solution > with creating a separate thread per URL > request will be much more efficient solution? It depends. What you describe is not nearly enough informatio to even give a suggestion. One thread per URL normally is a very poor choice (just as a matter of runtime efficiency), unless each URL causes you to do a lot of disk I/O, or if each URL causes you to do CPU intensive operations, like decode compressed audio/video. In each of those two situations, the process context switching costs are diminished relative to the type of work being done. Basically, the idea is that if your thread will block on an operation--CPU or I/O--but another thread running in parallel (not merely concurrently) could utilize additional resources, you want to multi-thread. If your application is merely moving bytes (say, as a proxy), usually a single thread is enough; you can multiplex non-blocking network operations on a single thread. In that sense, you're "switching contexts" in the application, and not the kernel. This reduces the workload, because context switching in the kernel is usually more expensive., OTOH, copying data in itself can be CPU intensive. If you read into a buffer from one socket, you might evict previous data you read in earlier. If you then try to re-read and/or copy that previous data over to another buffer later, the process will block as the data is fetched from RAM. If your proxy is even on a 100Mb connection, depending on how you process the data, you most definitely will need multiple threads. That's because 100Mb of network data could ballon to 5x or 10x that mount of byte shuffling. Of course, depending on how the L1, L2 and L3 caches are shared, it might not actually make much of a difference. It all depends! Of course, you can always use an event-oriented model within each particular thread. Or spread event delivery and processing across multiple threads. Given that you seem new to this (or at least new to the particular problem you're trying to solve), your best bet is to use a single thread using libevent, or go totally multi-threaded without libevent. In 90% of the circumstances one of those options (though not both) are as near to optimal as you'll get, and you don't need to the headaches of any additional complexity. > I saw that libevent was used in spybye, which is kind of similar what I > want to do. I was wondering if spybye were more efficient with requests > served in separate threads instead of using libevent (I don't say that > it's not efficient, just theoretically). I'm not sure, maybe its most efficient using _both_. But I suspect it probably just uses libevent in a single thread. Note, there are other ways to use threads. You could use one thread using libevent to handle all your queries and network I/O. Then you could use a separate thread worker pool to, for instance, run ClamAV on the data. This works well if you can isolate your CPU intensive work outside the mundane network I/O parts. If your application is overall CPU bound, and latency of particular requests isn't of primary concern, then it doesn't matter that libevent is running in a single thread. All your CPUs are doing work, just not the same types of work. From ron.arts at neonova.nl Mon Apr 7 09:07:34 2008 From: ron.arts at neonova.nl (Ron Arts) Date: Mon Apr 7 09:07:55 2008 Subject: [Libevent-users] Problems handling sigpipe in multithreaded program Message-ID: <47FA1C96.1070207@neonova.nl> Hi all, I am having problems with sigpipe handling. According to what I've read, if I ignore pipe signals before creating threads, all created threads will inherit this setting and ignore the sigpipes as well. My program's main thread uses libevent like this: sa.sa_handler = SIG_IGN; sa.sa_flags = 0; sigemptyset(&sa.sa_mask); sigaction(SIGPIPE, &sa, NULL); // libraries event_init(); g_thread_init(NULL); //create threads here fork(); event_dispatch(); But I still get occasional SIGPIPE errors which kill my program. These always happen in bufferevent_write, What can I do to solve this? Thanks, Ron -- NeoNova BV, The Netherlands Professional internet and VoIP solutions http://www.neonova.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628292 servicedesk: 020-5628292 fax: 020-5628291 KvK Amsterdam 34151241 The following disclaimer applies to this email: http://www.neonova.nl/maildisclaimer From damirn at gmail.com Mon Apr 7 09:19:29 2008 From: damirn at gmail.com (Damir Nedzibovic) Date: Mon Apr 7 09:19:46 2008 Subject: [Libevent-users] libevent 1.3e and MSVC 2005 Message-ID: <48e192860804070619y45cc96ecwe3905734f29811f3@mail.gmail.com> Hello people, I spent some time playing with the svn version of libevent 1.3e (https://levent.svn.sourceforge.net/svnroot/levent/branches/patches-1.3) and trying to build it with MS Visual Studio 2005. I also made some fixes to the code in order to get HTTP stuff working. In the attach you can find a patch against the latest svn version. I hope some of you will find this useful. Let me know if you have any problems with this. Ideas and comments are also welcomed. thanks, d -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: application/octet-stream Size: 7663 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20080407/a8b39d98/patch-0001.obj From nickm at freehaven.net Mon Apr 7 11:08:36 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Apr 7 12:06:29 2008 Subject: [Libevent-users] ANN: Libevent 1.4.3-stable released Message-ID: <20080407150836.GG26841@moria.seul.org> Hello, everyone! It's finally time to release a stable libevent again. Libevent 1.4.3-stable is now tagged and ready to go. You can get the source here: http://monkey.org/~provos/libevent-1.4.3-stable.tar.gz There are a few bug fixes since 1.4.2-rc. Here's a summary of what's changed since the last rc in this series: - Kqueue fixes - Make event_reinit() work properly with kqueue. - HTTP fixes: - We now include Content-Length when replying to HTTP/1.0 requests with keep-alive. - More functions in http.c are now threadsafe. - DNS fixes: - Stop deleting uninitialized timeout events. See the changelog for full details. This is only what's new since the last release candidate, 1.4.2-rc. The 1.4.x series as a whole has lots of new features since the 1.3 series. I'll send a copy of the "What's New" document to the list in my next message. Many thanks to everybody who sent in code, including Christopher Layne, Scott Lamb, and many others. Key bug reporters include Charles Kerr, Ilya Martynov, and others on sourceforge. To report a bug, make a feature request, or submit code, you can use our sourceforge interface here: https://sourceforge.net/projects/levent many thanks, -- Nick Mathewson From nickm at freehaven.net Mon Apr 7 11:11:00 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Apr 7 12:26:06 2008 Subject: [Libevent-users] What's New in Libevent 1.4 Message-ID: <20080407151100.GA24625@moria.seul.org> What's New In Libevent 1.4: 0. About this document This document describes the key differences between Libevent 1.3 and Libevent 1.4, from a user's point of view. It was most recently updated based on features from libevent 1.4.2-rc. 1. Packaging Issues. 1.1. The great library division. The libevent source now builds two libraries: libevent_core and libevent_extra. The libevent_core library includes event loops, timers, buffer code, and various small compatibility functions. The libevent_extra library includes code for HTTP, DNS, RPC, and so on. Thus, if you're writing software that only uses libevent's event loop, you should link against only the libevent_core library, whereas if you're writing software that uses libevent's protocol support as well, you need to link libevent_extra as well. For backward compatibility, libevent also builds a library called "libevent" that includes everything. 1.2. The event-config.h header Libevent configure script now builds two headers from its configure script: config.h (which it uses internally) and event-config.h (which it installs as a header file). All of the macros in event-config.h are modified so that they're safe to include in other projects. This allows libevent's header files (like event.h and evutil.h) information about platform configuration. What does this mean for you? As of 1.4.x, it should never be necessary to include extra files or define extra types before you include event.h (or any other libevent header); event.h can now look at the information in event-config.h and figure out what it needs to include. 1.3. Documentation Libevent now includes better doxygen documentation. It's not perfect or complete, though; if you find a mistake, please let us know. 1.4. Libtool usage We now use libtool's library versioning support correctly. If we don't mess this up, it means that binaries linked against old version of libevent should continue working when we make changes to libevent that don't break backward compatibility. 1.5. Portability Libevent now builds with MSVC again. We've only tested it with MSVC 2005, and the project files might not be right. Please let us know if you run into any issues. Libevent now builds on platforms where /bin/sh is not bash. Libevent's regression test no longer requires Python to be installed. 2. New and Improved APIs: (This list includes functions that are new, functions whose behavior has changed, and functions that were included in previous releases but which never actually worked before.) 2.1. Utility functions are defined in evutil.h Libevent now exposes a small set of functions for cross-platform network programming in evutil.h, on the theory that they've been useful enough to us that other people may likely want to use them too. These are mainly workarounds for Windows issues for now: they include evutil_socketpair (to fake socketpair on platforms that don't have it) and evutil_make_socket_nonblocking (to make a socket nonblocking in a cross-platform way. See the header for more information. 2.2. In the libevent core. The event_base_free() function now works. Previously, it would crash with an assertion failure if there were events pending on a base. Now, it simply deletes all the pending events and frees the base. Be careful -- this might leak fds and memory associated with the old events. To avoid leaks, you should still remove all the events and free their resources before you delete the base. Libevent should now work properly with fork(). Just call event_reinit() on your event base after the fork call, and it should work okay. Please let us know about any bugs you find. There's a new event_base_new() function that acts just like event_init(), but does not replace the default base. If you are using multiple event bases in your code, you should just use event_base_new() instead of event_init(), to avoid accidental bugs. There's new event_loopbreak() function to make a current event loop stop exiting and return. Unlike event_loopexit, it stops subsequent pending events from getting executed. This behavior is useful for scripting languages to implement exceptions from inside callbacks. There's a new event_base_get_method() function, for use in place of event_get_method() in multi-base applications. 2.3. New in HTTP. There's an evhttp_connection_set_local_address() function you can use to set the local address of an HTTP connection. HTTP/1.1 chunking now correctly ends chunks with '\r\n'. 2.4. New in DNS Instead of picking your method for generating DNS transaction IDs at startup, you can use evdns_set_transaction_id() to provide a transaction ID function at runtime. The "class" field in evdns_server_request is now renamed to dns_question_class, so that it won't break compilation under C++. This uses some preprocessor hacks so that C code using the old name won't break. Eventually, the old name will be deprecated entirely; please don't use it. 2.5. New in RPC There are now hooks on RPC input and output; can be used to implement RPC independent processing such as compression or authentication. RPC tags can now be up to 32 bits. This is wire-compatible, but changes some of the types in the APIs. Please let us know if this is problematic for you. 3. Big bugfixes We've done a lot, with help from users on different platforms, to make the different backends behave more similarly with respect to signals and timeouts. The kqueue and solaris backends were the big offenders previously, but they should be better now. Windows should be better too, though it's likely that problems remain there. The libevent headers (though not the source files!) should now build cleanly on C++. (For more bugfixes, see the ChangeLog file. These are only the biggies.) 4. Big performance improvements Libevent now uses a min-heap rather than a red-black tree to track timeouts. This means that finding the next timeout to fire is now O(1) instead of (lg n). The win32 select-based backend now uses a red-black tree to map SOCKET handles to event structures. This changes the performance characteristics of the event loop on win32 from O(n^2) to O(n lg n). Not perfect, but better. 5. Removed code and features The rtsig backend is now removed. It hasn't even compiled for a while, and nobody seemed to miss it very much. All the platforms that have rtsig seem to have a better option instead these days. Please let us know if rtsig was crucial for you. From nseward at gmail.com Tue Apr 8 14:05:13 2008 From: nseward at gmail.com (Nick Seward) Date: Tue Apr 8 14:06:44 2008 Subject: [Libevent-users] Compiling on AIX Message-ID: <1e7b50ad0804081105mc09a06as7ab43dc15ccd42c5@mail.gmail.com> Hi, I've searched the mailing list archive for people having problems compiling libevent on AIX. I didn't find much that I could understand. I am using AIX 5.2 and libevent 1.4.2-rc. Here is my output of running ./configure. checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... none checking for a BSD-compatible install... ./install-sh -c checking whether ln -s works... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking whether gcc needs -traditional... no checking build system type... powerpc-ibm-aix5.2.0.0 checking host system type... powerpc-ibm-aix5.2.0.0 checking for a sed that does not truncate output... /usr/bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognize dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... xlC_r checking whether we are using the GNU C++ compiler... no checking whether xlC_r accepts -g... no checking dependency style of xlC_r... none checking how to run the C++ preprocessor... xlC_r -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 18432 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... aix5.2.0.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... yes libtool.m4: error: problem compiling CXX test program checking for xlC_r option to produce PIC... checking if xlC_r static flag -bnso -bI:/lib/syscalls.exp works... no checking if xlC_r supports -c -o file.o... no checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... aix5.2.0.0 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for socket in -lsocket... no checking for inet_aton in -lresolv... no checking for clock_gettime in -lrt... yes checking for inet_ntoa in -lnsl... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking stdarg.h usability... yes checking stdarg.h presence... yes checking for stdarg.h... yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking for unistd.h... (cached) yes checking sys/epoll.h usability... no checking sys/epoll.h presence... no checking for sys/epoll.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/queue.h usability... yes checking sys/queue.h presence... yes checking for sys/queue.h... yes checking sys/event.h usability... no checking sys/event.h presence... no checking for sys/event.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/devpoll.h usability... no checking sys/devpoll.h presence... no checking for sys/devpoll.h... no checking port.h usability... no checking port.h presence... no checking for port.h... no checking netinet/in6.h usability... no checking netinet/in6.h presence... no checking for netinet/in6.h... no checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for TAILQ_FOREACH in sys/queue.h... no checking for timeradd in sys/time.h... no checking for timercmp in sys/time.h... yes checking for timerclear in sys/time.h... yes checking for timerisset in sys/time.h... yes checking for WIN32... no checking for an ANSI C-conforming const... yes checking for inline... inline checking whether time.h and sys/time.h may both be included... yes checking for gettimeofday... yes checking for vasprintf... no checking for fcntl... yes checking for clock_gettime... yes checking for strtok_r... yes checking for strsep... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for strlcpy... no checking for inet_ntop... yes checking for signal... yes checking for sigaction... yes checking for strtoll... yes checking for long... yes checking size of long... 4 checking for F_SETFD in fcntl.h... yes checking for select... yes checking for poll... yes checking for epoll_ctl... no checking for port_create... no checking for pid_t... yes checking for size_t... yes checking for uint64_t... yes checking for uint32_t... yes checking for uint16_t... yes checking for uint8_t... yes checking for long long... yes checking size of long long... 8 checking for long... (cached) yes checking size of long... (cached) 4 checking for int... yes checking size of int... 4 checking for short... yes checking size of short... 2 checking for struct in6_addr... yes checking for socklen_t... yes checking whether our compiler supports __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating test/Makefile config.status: creating sample/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands After that I tried running make and was given the following error: # make make all-recursive Making all in . /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -Wall -release 1.4 -version-info 2:0:0 -o libevent.la -rpath /usr/local/lib event.lo buffer.lo evbuffer.lo log.lo evutil.lo event_tagging.lo http.lo evdns.lo evrpc.lo strlcpy.lo select.lo poll.lo signal.lo -lnsl -lrt rm -fr .libs/libevent.exp generating symbol list for `libevent.la' /usr/bin/nm -B -BCpg .libs/event.o .libs/buffer.o .libs/evbuffer.o .libs/log.o .libs/evutil.o .libs/event_tagging.o .libs/http.o .libs/evdns.o .libs/evrpc.o .libs/strlcpy.o .libs/select.o .libs/poll.o .libs/signal.o | awk '{ if ((($2 == "T") || ($2 == "D") || ($2 == "B")) && (substr($3,1,1) != ".")) { print $3 } }' | sort -u > .libs/libevent.exp gcc -shared -o .libs/libevent-1.4.so.2 .libs/event.o .libs/buffer.o .libs/evbuffer.o .libs/log.o .libs/evutil.o .libs/event_tagging.o .libs/http.o .libs/evdns.o .libs/evrpc.o .libs/strlcpy.o .libs/select.o .libs/poll.o .libs/signal.o -lnsl -lrt -lc -Wl,-bnoentry -Wl,-bE:.libs/libevent.exp ${wl}-berok collect2: library libgcc_s not found make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. Does anyone know what this problem is? Thanks in advance for any help that can be provided, Nick From Joerg.Richter at pdv-FS.de Wed Apr 9 03:26:48 2008 From: Joerg.Richter at pdv-FS.de (=?iso-8859-1?Q?Richter=2C_J=F6rg?=) Date: Wed Apr 9 03:27:20 2008 Subject: [Libevent-users] Compiling on AIX In-Reply-To: <1e7b50ad0804081105mc09a06as7ab43dc15ccd42c5@mail.gmail.com> References: <1e7b50ad0804081105mc09a06as7ab43dc15ccd42c5@mail.gmail.com> Message-ID: Hi, >I've searched the mailing list archive for people having problems >compiling libevent on AIX. I didn't find much that I could understand. >I am using AIX 5.2 and libevent 1.4.2-rc. Sorry, I can't really help. I can only confirm that I recently compiled 1.4.2-rc on AIX 5.2 and got no problems at all. J?rg From oyscal at gmail.com Thu Apr 10 01:12:30 2008 From: oyscal at gmail.com (Elvis Chou) Date: Thu Apr 10 01:12:48 2008 Subject: [Libevent-users] compile issues on windows Message-ID: <6e4343160804092212l6b0b9bc4q97cfa49c78a0b987@mail.gmail.com> hi all,I failed to compile this project on windows,using the latest trunk. there is a vs2008 project file in WIN32-Prj folder ,I just open it and build,but it complains can't find inttypes.h, where can I get those files ?, or any other solution? many thanks~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20080410/e772a0d7/attachment.htm From provos at citi.umich.edu Thu Apr 10 11:12:08 2008 From: provos at citi.umich.edu (Niels Provos) Date: Thu Apr 10 11:12:30 2008 Subject: [Libevent-users] compile issues on windows In-Reply-To: <6e4343160804092212l6b0b9bc4q97cfa49c78a0b987@mail.gmail.com> References: <6e4343160804092212l6b0b9bc4q97cfa49c78a0b987@mail.gmail.com> Message-ID: <850f7cbe0804100812q41b838d7y12a6ce99f5329b14@mail.gmail.com> Hi Elvis, thank you for your bug report. It is being tracked at https://sourceforge.net/tracker/index.php?func=detail&aid=1939494&group_id=50884&atid=461322 Niels. From rich at zkonsult.com Sun Apr 13 20:11:41 2008 From: rich at zkonsult.com (Rich Onyon) Date: Sun Apr 13 20:12:06 2008 Subject: [Libevent-users] libevent regress tests failing. Message-ID: <200804140011.m3E0BoXQ001414@flpi185.prodigy.net> I'm having a problem compiling libevent. Upon doing a make verify the regress tests are failing. Output and system version information below. [root@zkonsult libevent-1.4.3-stable]# make verify cd test && make verify make[1]: Entering directory `/root/libevent-1.4.3-stable/test' Running tests: KQUEUE Skipping test DEVPOLL Skipping test POLL test-eof: OKAY test-weof: OKAY test-time: OKAY regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl: 460: 2001:1890:1112:1::20 FAILED SELECT test-eof: OKAY test-weof: OKAY test-time: OKAY regress: type: 1, count: 1, ttl: 290: 152.160.49.201 type: 3, count: 1, ttl: 450: 2001:1890:1112:1::20 FAILED EPOLL test-eof: OKAY test-weof: OKAY test-time: OKAY regress: type: 1, count: 1, ttl: 280: 152.160.49.201 type: 3, count: 1, ttl: 440: 2001:1890:1112:1::20 FAILED EVPORT Skipping test make[1]: Leaving directory `/root/libevent-1.4.3-stable/test' System Information Below. [root@zkonsult libevent-1.4.3-stable]# gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) [root@zkonsult libevent-1.4.3-stable]# cat /proc/version Linux version 2.6.20-1.2320.fc5 (brewbuilder@ls20-bc1-14.build.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Tue Jun 12 18:50:49 EDT 2007 Rich From provos at citi.umich.edu Sun Apr 13 20:39:27 2008 From: provos at citi.umich.edu (Niels Provos) Date: Sun Apr 13 20:39:35 2008 Subject: [Libevent-users] libevent regress tests failing. In-Reply-To: <200804140011.m3E0BoXQ001414@flpi185.prodigy.net> References: <200804140011.m3E0BoXQ001414@flpi185.prodigy.net> Message-ID: <850f7cbe0804131739x30c5536cl2b60b8db234c7c7d@mail.gmail.com> On Sun, Apr 13, 2008 at 5:11 PM, Rich Onyon wrote: > I'm having a problem compiling libevent. Upon doing a make verify the > regress tests are failing. Output and system version information below. It looks like they are all failing in the same way. Please, send the output of running $ ./test/regress Thanks, Niels. From rich at zkonsult.com Sun Apr 13 20:54:50 2008 From: rich at zkonsult.com (Rich Onyon) Date: Sun Apr 13 20:55:05 2008 Subject: [Libevent-users] libevent regress tests failing. In-Reply-To: <850f7cbe0804131739x30c5536cl2b60b8db234c7c7d@mail.gmail.com> Message-ID: <200804140055.m3E0t0a9012299@flpi101.prodigy.net> Thanks for the quick reply Niels; Results below. [root@zkonsult libevent-1.4.3-stable]# test/regress evutil_stroll: OK Testing Priorities 1: OK Testing Priorities 2: OK Testing Priorities 3: OK Testing Evbuffer: OK Testing evbuffer_find 1: OK Testing evbuffer_find 2: OK Testing evbuffer_find 3: OK Bufferevent: OK Free active base: OK Event base new: OK Testing HTTP Server Event Base: OK Testing HTTP Header filtering: OK Testing Basic HTTP Server: OK Testing Request Connection Pipeline : OK Testing Request Connection Pipeline (persistent): OK Testing Connection Close Detection: OK Testing HTTP POST Request: OK Testing Bad HTTP Request: OK Testing HTTP Server with high port: OK Testing HTTP Dispatcher: OK Testing Basic RPC Support: OK Testing Good RPC Post: OK Testing RPC Client: OK Testing RPC (Queued) Client: OK Testing RPC Client Timeout: OK DNS server support: OK Simple DNS resolve: type: 1, count: 1, ttl: 300: 152.160.49.201 OK IPv6 DNS resolve: type: 3, count: 1, ttl: 1800: 2001:1890:1112:1::20 OK Simple reverse DNS resolve: [Error code 3] FAILED [root@zkonsult libevent-1.4.3-stable]# ping yahoo.com PING yahoo.com (66.94.234.13) 56(84) bytes of data. 64 bytes from w2.rc.vip.scd.yahoo.com (66.94.234.13): icmp_seq=1 ttl=57 time=2.43 ms 64 bytes from w2.rc.vip.scd.yahoo.com (66.94.234.13): icmp_seq=2 ttl=57 time=1.97 ms -----Original Message----- From: provos@gmail.com [mailto:provos@gmail.com] On Behalf Of Niels Provos Sent: Sunday, April 13, 2008 5:39 PM To: Rich Onyon Cc: libevent-users@monkey.org Subject: Re: [Libevent-users] libevent regress tests failing. On Sun, Apr 13, 2008 at 5:11 PM, Rich Onyon wrote: > I'm having a problem compiling libevent. Upon doing a make verify the > regress tests are failing. Output and system version information below. It looks like they are all failing in the same way. Please, send the output of running $ ./test/regress Thanks, Niels. From liusifan at gmail.com Wed Apr 16 11:10:46 2008 From: liusifan at gmail.com (liusifan) Date: Wed Apr 16 11:11:58 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 Message-ID: <200804162310435768324@gmail.com> Hi, all Compile the following svn version success with VC6. https://levent.svn.sourceforge.net/svnroot/levent/tags/release-1.4.3-stable Step 1 Add VC6 project files, please check as attachment Step 2 Modify WIN32-Code/event-config.h, buffer.c, evutil.h diff -r release-1.4.3-stable/libevent/WIN32-Code/event-config.h libevent143/WIN32-Code/event-config.h 53,54c53,56 < /* Define to 1 if you have the header file. */ < #define _EVENT_HAVE_INTTYPES_H 1 --- > /* Define to 1 if you have the header file. */ > #if defined(_MSG_VER) && _MSC_VER >= 1300 > #define _EVENT_HAVE_INTTYPES_H 1 > #endif Only in libevent143/: WIN32-VC6 diff -r release-1.4.3-stable/libevent/buffer.c libevent143/buffer.c 158c158 < sz = vsnprintf(buffer, space - 1, fmt, aq); --- > sz = _vsnprintf(buffer, space - 1, fmt, aq); diff -r release-1.4.3-stable/libevent/evutil.h libevent143/evutil.h 57c57 < #elif defined(WIN32) --- > #elif defined(WIN32) 59c59,63 < #define ev_int64_t __int64_t --- > #if ( _MSC_VER < 1300 ) > #define ev_int64_t __int64 > #else > #define ev_int64_t __int64_t > #endif Best Regards, Stephen Liu 2008-04-16 -------------- next part -------------- A non-text attachment was scrubbed... Name: WIN32-VC6.zip Type: application/octet-stream Size: 1583 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20080416/b9fb2097/WIN32-VC6.obj From richard at opendns.com Wed Apr 16 11:58:12 2008 From: richard at opendns.com (Richard Crowley) Date: Wed Apr 16 11:58:29 2008 Subject: [Libevent-users] Closing connection after bufferevent_write Message-ID: <48062214.3060308@opendns.com> I am using an event_dispatch() loop as the basis for a server listening on a socket and would like to terminate connections forcefully from the server. The ideal flow would be: listen, client connects, event loop dispatches to my bufferevent where I accept the connection, the read callback is called and a response is given to the bufferevent, and the connection is closed (of course the main socket is still listening). Here is some stripped-down sample code illustrating my code structure so far. In the on_read() function, I read from the client's request, compute a response and write the response using bufferevent_write(). Is there a way to close the connection after that data is written? Currently I'm using special header and footer markers in the response data so the client can figure out when the response has ended and close the connection itself. However, it would be nice if the server could close the connection so I won't have to have this logic in the client. void on_read(struct bufferevent * bev, void * arg) { // ... char buf[4096]; size_t len = bufferevent_read(bev, (void *)buf, 4096); // ... bufferevent_write(bev, "foo\n", 4); // *** I would like to close the connection after this write } void on_accept(int fd, short ev, void * arg) { // ... struct client * client = calloc(1, sizeof(struct client)); if (!client) { fprintf(stderr, "Error: Call to calloc failed.\n"); exit(1); } client->fd = client_fd; client->buf_ev = bufferevent_new(client_fd, on_read, on_write, on_error, client); bufferevent_enable(client->buf_ev, EV_READ); } int main(int argc, char * * argv) { // ... struct event ev_accept; event_set(&ev_accept, listen_fd, EV_READ|EV_PERSIST, on_accept, 0); event_add(&ev_accept, 0); event_dispatch(); return 0; } Any help you can offer would be most appreciated. Thanks, Richard richard@opendns.com From 404emailnotfound at gmail.com Thu Apr 17 00:30:49 2008 From: 404emailnotfound at gmail.com (Matt Pearson) Date: Thu Apr 17 00:31:09 2008 Subject: [Libevent-users] Closing connection after bufferevent_write In-Reply-To: <48062214.3060308@opendns.com> References: <48062214.3060308@opendns.com> Message-ID: <706b4240804162130p1ce53634l19d88be4e11e072d@mail.gmail.com> Yes, just specify a write callback on the bufferevent and enable writes. It will call the callback when its buffer is empty, and then you can free the bufferevent and close the file descriptor. If this could happen multiple times and you only want it to close on the last one, then just add some sort of flag to struct client. (On an unrelated note, Gmail seems to think a lot of traffic on this list is spam. Does that happen for everyone else?) From nickm at freehaven.net Thu Apr 17 14:51:04 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Thu Apr 17 14:55:47 2008 Subject: [Libevent-users] [patch] replace linear search in evdns with hashed list and add support of listening on unix sockets for evhttp In-Reply-To: <47B9AB28.6000909@highsecure.ru> References: <47B5BC4A.3010905@highsecure.ru> <20080216172630.GC21803@moria.seul.org> <47B980E1.60006@highsecure.ru> <47B9AAA0.8040706@highsecure.ru> <47B9AB28.6000909@highsecure.ru> Message-ID: <20080417185104.GA17168@moria.seul.org> On Mon, Feb 18, 2008 at 06:58:32PM +0300, Vsevolod Stakhov wrote: [...] > >I've made some modifications to patch to attract your wishes, thought > >I've not tested it in production yet. > > Sorry, attached reversed diff. > Hi, and sorry about the delay! Now that libevent 1.4 is stable, I'm able to spend more time getting more patches into the next series. I did a match to make evdns.c threadsafe, but after I did so your patch no longer applied cleanly. I've done an updated version of your patch and attached it here; could you test it out and let me know if it works for you and does what you want under load? You'll need to apply it to svn trunk; it won't work with 1.4. I'm still curious whether evdns_transmit() shows up on your profiles: it's the only remaining common case where we walk the list of all inflight requests. As you said before, your patch shouldn't make it any slower, but I'm curious whether it appears slow for you at all. If so, there should be another list of requests for which transmit_me is set, so we don't need to walk the whole list of inflight requests just in order to retry those. yrs, -- Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: evdns_multihead.diff Type: text/x-diff Size: 10545 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20080417/539bf30c/evdns_multihead-0001.bin From C.Rzewuski at elka.pw.edu.pl Fri Apr 18 16:36:53 2008 From: C.Rzewuski at elka.pw.edu.pl (Cezary Rzewuski) Date: Fri Apr 18 16:43:00 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <20080403050439.GB883@wilbur.25thandClement.com> References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> Message-ID: <48090665.3090906@elka.pw.edu.pl> Thank you for Your suggestions. I've just finished the implementation. I used the approach of libevent as HTTP server and threads working on downloaded content (they are performing some statistical computation on downloaded javascripts). It looks to work efficiently. It's probably not the right group, but you says that switching between threads is expensive. However, I've read somewhere (it was probably "Advanced linux programming" by Alex Samuel) that creating a new thread is nearly as fast as calling a function. Does it mean, that switching between threads is slower than creating a new thread? Once more - thanks for comprehensive answer. William Ahern wrote: > On Wed, Apr 02, 2008 at 10:15:59PM +0200, Cezary Rzewuski wrote: > >> Hi, >> I'd like to ask if sending http requests with libevent is carried out in >> separate thread or is the library >> single-threaded? I want to use the library in a program which will visit >> many URL and download >> it's content. Is it good idea to use libevent or the classic solution >> with creating a separate thread per URL >> request will be much more efficient solution? >> > > It depends. What you describe is not nearly enough informatio to even give a > suggestion. > > One thread per URL normally is a very poor choice (just as a matter of > runtime efficiency), unless each URL causes you to do a lot of disk I/O, or > if each URL causes you to do CPU intensive operations, like decode > compressed audio/video. In each of those two situations, the process context > switching costs are diminished relative to the type of work being done. > > Basically, the idea is that if your thread will block on an operation--CPU > or I/O--but another thread running in parallel (not merely concurrently) > could utilize additional resources, you want to multi-thread. > > If your application is merely moving bytes (say, as a proxy), usually a > single thread is enough; you can multiplex non-blocking network operations > on a single thread. In that sense, you're "switching contexts" in the > application, and not the kernel. This reduces the workload, because context > switching in the kernel is usually more expensive., > > OTOH, copying data in itself can be CPU intensive. If you read into a buffer > from one socket, you might evict previous data you read in earlier. If you > then try to re-read and/or copy that previous data over to another buffer > later, the process will block as the data is fetched from RAM. If your proxy > is even on a 100Mb connection, depending on how you process the data, you > most definitely will need multiple threads. That's because 100Mb of network > data could ballon to 5x or 10x that mount of byte shuffling. Of course, > depending on how the L1, L2 and L3 caches are shared, it might not actually > make much of a difference. It all depends! > > Of course, you can always use an event-oriented model within each particular > thread. Or spread event delivery and processing across multiple threads. > > Given that you seem new to this (or at least new to the particular problem > you're trying to solve), your best bet is to use a single thread using > libevent, or go totally multi-threaded without libevent. In 90% of the > circumstances one of those options (though not both) are as near to optimal > as you'll get, and you don't need to the headaches of any additional > complexity. > > >> I saw that libevent was used in spybye, which is kind of similar what I >> want to do. I was wondering if spybye were more efficient with requests >> served in separate threads instead of using libevent (I don't say that >> it's not efficient, just theoretically). >> > > I'm not sure, maybe its most efficient using _both_. But I suspect it > probably just uses libevent in a single thread. > > Note, there are other ways to use threads. You could use one thread using > libevent to handle all your queries and network I/O. Then you could use a > separate thread worker pool to, for instance, run ClamAV on the data. This > works well if you can isolate your CPU intensive work outside the mundane > network I/O parts. If your application is overall CPU bound, and latency of > particular requests isn't of primary concern, then it doesn't matter that > libevent is running in a single thread. All your CPUs are doing work, just > not the same types of work. > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > > From springandeulv at gmail.com Fri Apr 18 18:23:16 2008 From: springandeulv at gmail.com (Springande Ulv) Date: Fri Apr 18 18:23:36 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <48090665.3090906@elka.pw.edu.pl> References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> <48090665.3090906@elka.pw.edu.pl> Message-ID: <90E08FCC-37EF-4ED2-A166-3022E0F11BB8@gmail.com> On 18. april. 2008, at 22.36, Cezary Rzewuski wrote: >> our best bet is to use a single thread using >> libevent, or go totally multi-threaded without libevent. In 90% of >> the >> circumstances one of those options (though not both) Why not both?! Using both threads _and_ libevent is not only possible both often feasible. Use libevent in a i/o bound thread and a thread pool for CPU bound operations. In a network application the network is the bottleneck and a few context switches is diminutive in this context. From william at 25thandClement.com Fri Apr 18 19:57:46 2008 From: william at 25thandClement.com (William Ahern) Date: Fri Apr 18 19:57:58 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <90E08FCC-37EF-4ED2-A166-3022E0F11BB8@gmail.com> References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> <48090665.3090906@elka.pw.edu.pl> <90E08FCC-37EF-4ED2-A166-3022E0F11BB8@gmail.com> Message-ID: <20080418235746.GA1480@wilbur.25thandClement.com> On Sat, Apr 19, 2008 at 12:23:16AM +0200, Springande Ulv wrote: > > On 18. april. 2008, at 22.36, Cezary Rzewuski wrote: > >>our best bet is to use a single thread using > >>libevent, or go totally multi-threaded without libevent. In 90% of > >>the > >>circumstances one of those options (though not both) > > Why not both?! Using both threads _and_ libevent is not only possible > both often feasible. Use libevent in a i/o bound thread and a thread > pool for CPU bound operations. In a network application the network is > the bottleneck and a few context switches is diminutive in this context. Because _unless_ you can justify the additional complexity, why bother? In some sense--like code complexity--using both an event-oriented design *and* threads is the worst of both worlds. Your processing logic is turned inside-out (state machines, etc, can be confusing to some people), plus you have mutexes and barriers and all that crap littered throughout your code. I've used libevent with threads. I've also used libevent with multi-process configurations. But, usually I stick with one or the other. Premature optimization is the root of all evil.... From springandeulv at gmail.com Fri Apr 18 20:49:20 2008 From: springandeulv at gmail.com (Springande Ulv) Date: Fri Apr 18 20:49:30 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <20080418235746.GA1480@wilbur.25thandClement.com> References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> <48090665.3090906@elka.pw.edu.pl> <90E08FCC-37EF-4ED2-A166-3022E0F11BB8@gmail.com> <20080418235746.GA1480@wilbur.25thandClement.com> Message-ID: On 19. april. 2008, at 01.57, William Ahern wrote: > In some sense--like code complexity--using both an event-oriented > design > *and* threads is the worst of both worlds. Your processing logic is > turned > inside-out (state machines, etc, can be confusing to some people), > plus you > have mutexes and barriers and all that crap littered throughout your > code. He he, the crack you just heard is the thin ice you walked out on. > Premature optimization is the root of all evil.... Oh that is an old misunderstood meme. What Hoare actually said was "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." He was talking about micro-optimizing code. Not exactly what I would call thinking about a scalable program design, which one should think about from the start and at all time, unless you work in the Microsoft Office team. From william at 25thandClement.com Sat Apr 19 00:18:03 2008 From: william at 25thandClement.com (William Ahern) Date: Sat Apr 19 00:18:16 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> <48090665.3090906@elka.pw.edu.pl> <90E08FCC-37EF-4ED2-A166-3022E0F11BB8@gmail.com> <20080418235746.GA1480@wilbur.25thandClement.com> Message-ID: <20080419041803.GA18715@wilbur.25thandClement.com> On Sat, Apr 19, 2008 at 02:49:20AM +0200, Springande Ulv wrote: > > On 19. april. 2008, at 01.57, William Ahern wrote: > >In some sense--like code complexity--using both an event-oriented > >design > >*and* threads is the worst of both worlds. Your processing logic is > >turned > >inside-out (state machines, etc, can be confusing to some people), > >plus you > >have mutexes and barriers and all that crap littered throughout your > >code. > > He he, the crack you just heard is the thin ice you walked out on. I must be deaf. > >Premature optimization is the root of all evil.... > > Oh that is an old misunderstood meme. What Hoare actually said was "We > should forget about small efficiencies, say about 97% of the time: > premature optimization is the root of all evil." He was talking about > micro-optimizing code. Not exactly what I would call thinking about a > scalable program design, which one should think about from the start > and at all time, unless you work in the Microsoft Office team. I really couldn't care less what Hoare or anybody else said. I'm not appealing to authority. It's an apposite phrase. If you fancy all your first or even second iterations of your projects running a gigantic data center, *and* you actually meet your targets out the gate, then good for you. (Normal people would write a proof-of-concept first, and maybe second, and third.) But, in my experience it's best to aim for correctness first. If you must, you can fix most any well designed single process event-oriented daemon to scale [more] by tweaking it to use multiple processes, or multiple servers. The same more-or-less goes for threaded servers. But you usually don't need to, because as long as you're not needlessly copying data or doing other wasteful things, then you'll best any second-rate application, period. From william at 25thandClement.com Sat Apr 19 00:23:19 2008 From: william at 25thandClement.com (William Ahern) Date: Sat Apr 19 00:23:28 2008 Subject: [Libevent-users] http: libevent vs many threads In-Reply-To: <48090665.3090906@elka.pw.edu.pl> References: <47F3E97F.3010400@elka.pw.edu.pl> <20080403050439.GB883@wilbur.25thandClement.com> <48090665.3090906@elka.pw.edu.pl> Message-ID: <20080419042319.GB18715@wilbur.25thandClement.com> On Fri, Apr 18, 2008 at 10:36:53PM +0200, Cezary Rzewuski wrote: > Thank you for Your suggestions. I've just finished the implementation. > I used the approach of libevent as HTTP server and threads working > on downloaded content (they are performing some statistical computation on > downloaded javascripts). It looks to work efficiently. > > It's probably not the right group, but you says that switching between > threads > is expensive. However, I've read somewhere (it was probably "Advanced linux > programming" by Alex Samuel) that creating a new thread is nearly as fast as > calling a function. Does it mean, that switching between threads is > slower than > creating a new thread? Creating a new thread is almost certainly not as fast as calling a function. Maybe, I suppose, as fast calling into the kernel; author's point being that Linux can quickly allocate and setup the task structures. But this sounds like one of those things you should test yourself. I'm not quite sure what the benchmark would look like. Try Usenet: comp.unix.programmer, or comp.programming.threads. From ebgssth at gmail.com Sat Apr 19 09:02:47 2008 From: ebgssth at gmail.com (js) Date: Sat Apr 19 09:02:54 2008 Subject: [Libevent-users] event-test on OS X Message-ID: Hi, I found event-test sample doesn't work on OS X. It seems this is a known problem because I found similar report on the list: http://monkeymail.org/archives/libevent-users/2006-October/000259.html The report above suggests using fcntl to get REAL O_NONBLOCK, so I added the code below if ((flags = fcntl (socket, F_GETFL, 0)) == -1) { perror("fcntl"); exit (1); } flags |= O_NONBLOCK; if (fcntl (socket, F_SETFL, flags) == -1) { perror("fcntl"); exit (1); } but it didn't work for me. and I confirmed that open(O_NONBLOCK) set O_NONBLOCK to socket succesfully by using fcntl F_GETFL. I'm stuck. Any clues? From nseward at gmail.com Sat Apr 19 17:53:52 2008 From: nseward at gmail.com (Nick Seward) Date: Sat Apr 19 17:54:10 2008 Subject: [Libevent-users] Re: Compiling on AIX In-Reply-To: <1e7b50ad0804081105mc09a06as7ab43dc15ccd42c5@mail.gmail.com> References: <1e7b50ad0804081105mc09a06as7ab43dc15ccd42c5@mail.gmail.com> Message-ID: <1e7b50ad0804191453m6f5db06av54b430f1a2816fe0@mail.gmail.com> I managed to figure out my problem. A GCC library wasn't in a location that the Makefile could find. Copying this library to /usr/lib fixed the problem. Nick On Tue, Apr 8, 2008 at 2:05 PM, Nick Seward wrote: > Hi, > > I've searched the mailing list archive for people having problems > compiling libevent on AIX. I didn't find much that I could understand. > I am using AIX 5.2 and libevent 1.4.2-rc. > > Here is my output of running ./configure. > > checking for a BSD-compatible install... ./install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking for a BSD-compatible install... ./install-sh -c > checking whether ln -s works... yes > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking whether gcc needs -traditional... no > checking build system type... powerpc-ibm-aix5.2.0.0 > checking host system type... powerpc-ibm-aix5.2.0.0 > checking for a sed that does not truncate output... /usr/bin/sed > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... no > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking how to recognize dependent libraries... pass_all > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... no > checking for c++... no > checking for gpp... no > checking for aCC... no > checking for CC... no > checking for cxx... no > checking for cc++... no > checking for cl.exe... no > checking for FCC... no > checking for KCC... no > checking for RCC... no > checking for xlC_r... xlC_r > checking whether we are using the GNU C++ compiler... no > checking whether xlC_r accepts -g... no > checking dependency style of xlC_r... none > checking how to run the C++ preprocessor... xlC_r -E > checking for g77... no > checking for xlf... no > checking for f77... no > checking for frt... no > checking for pgf77... no > checking for cf77... no > checking for fort77... no > checking for fl32... no > checking for af77... no > checking for xlf90... no > checking for f90... no > checking for pgf90... no > checking for pghpf... no > checking for epcf90... no > checking for gfortran... no > checking for g95... no > checking for xlf95... no > checking for f95... no > checking for fort... no > checking for ifort... no > checking for ifc... no > checking for efc... no > checking for pgf95... no > checking for lf95... no > checking for ftn... no > checking whether we are using the GNU Fortran 77 compiler... no > checking whether accepts -g... no > checking the maximum length of command line arguments... 18432 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... > checking if gcc static flag -static works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... aix5.2.0.0 ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... no > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... yes > libtool.m4: error: problem compiling CXX test program > checking for xlC_r option to produce PIC... > checking if xlC_r static flag -bnso -bI:/lib/syscalls.exp works... no > checking if xlC_r supports -c -o file.o... no > checking whether the xlC_r linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... aix5.2.0.0 ld.so > checking how to hardcode library paths into programs... immediate > appending configuration tag "F77" to libtool > checking for socket in -lsocket... no > checking for inet_aton in -lresolv... no > checking for clock_gettime in -lrt... yes > checking for inet_ntoa in -lnsl... yes > checking for ANSI C header files... (cached) yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking stdarg.h usability... yes > checking stdarg.h presence... yes > checking for stdarg.h... yes > checking for inttypes.h... (cached) yes > checking for stdint.h... (cached) yes > checking poll.h usability... yes > checking poll.h presence... yes > checking for poll.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking for unistd.h... (cached) yes > checking sys/epoll.h usability... no > checking sys/epoll.h presence... no > checking for sys/epoll.h... no > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/queue.h usability... yes > checking sys/queue.h presence... yes > checking for sys/queue.h... yes > checking sys/event.h usability... no > checking sys/event.h presence... no > checking for sys/event.h... no > checking sys/param.h usability... yes > checking sys/param.h presence... yes > checking for sys/param.h... yes > checking sys/ioctl.h usability... yes > checking sys/ioctl.h presence... yes > checking for sys/ioctl.h... yes > checking sys/select.h usability... yes > checking sys/select.h presence... yes > checking for sys/select.h... yes > checking sys/devpoll.h usability... no > checking sys/devpoll.h presence... no > checking for sys/devpoll.h... no > checking port.h usability... no > checking port.h presence... no > checking for port.h... no > checking netinet/in6.h usability... no > checking netinet/in6.h presence... no > checking for netinet/in6.h... no > checking sys/socket.h usability... yes > checking sys/socket.h presence... yes > checking for sys/socket.h... yes > checking for TAILQ_FOREACH in sys/queue.h... no > checking for timeradd in sys/time.h... no > checking for timercmp in sys/time.h... yes > checking for timerclear in sys/time.h... yes > checking for timerisset in sys/time.h... yes > checking for WIN32... no > checking for an ANSI C-conforming const... yes > checking for inline... inline > checking whether time.h and sys/time.h may both be included... yes > checking for gettimeofday... yes > checking for vasprintf... no > checking for fcntl... yes > checking for clock_gettime... yes > checking for strtok_r... yes > checking for strsep... yes > checking for getaddrinfo... yes > checking for getnameinfo... yes > checking for strlcpy... no > checking for inet_ntop... yes > checking for signal... yes > checking for sigaction... yes > checking for strtoll... yes > checking for long... yes > checking size of long... 4 > checking for F_SETFD in fcntl.h... yes > checking for select... yes > checking for poll... yes > checking for epoll_ctl... no > checking for port_create... no > checking for pid_t... yes > checking for size_t... yes > checking for uint64_t... yes > checking for uint32_t... yes > checking for uint16_t... yes > checking for uint8_t... yes > checking for long long... yes > checking size of long long... 8 > checking for long... (cached) yes > checking size of long... (cached) 4 > checking for int... yes > checking size of int... 4 > checking for short... yes > checking size of short... 2 > checking for struct in6_addr... yes > checking for socklen_t... yes > checking whether our compiler supports __func__... yes > configure: creating ./config.status > config.status: creating Makefile > config.status: creating test/Makefile > config.status: creating sample/Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > > > After that I tried running make and was given the following error: > > # make > make all-recursive > Making all in . > /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -Wall > -release 1.4 -version-info 2:0:0 -o libevent.la -rpath /usr/local/lib > event.lo buffer.lo evbuffer.lo log.lo evutil.lo event_tagging.lo > http.lo evdns.lo evrpc.lo strlcpy.lo select.lo poll.lo signal.lo > -lnsl -lrt > rm -fr .libs/libevent.exp > generating symbol list for `libevent.la' > /usr/bin/nm -B -BCpg .libs/event.o .libs/buffer.o .libs/evbuffer.o > .libs/log.o .libs/evutil.o .libs/event_tagging.o .libs/http.o > .libs/evdns.o .libs/evrpc.o .libs/strlcpy.o .libs/select.o > .libs/poll.o .libs/signal.o | awk '{ if ((($2 == "T") || ($2 == "D") > || ($2 == "B")) && (substr($3,1,1) != ".")) { print $3 } }' | sort -u > > .libs/libevent.exp > gcc -shared -o .libs/libevent-1.4.so.2 .libs/event.o .libs/buffer.o > .libs/evbuffer.o .libs/log.o .libs/evutil.o .libs/event_tagging.o > .libs/http.o .libs/evdns.o .libs/evrpc.o .libs/strlcpy.o > .libs/select.o .libs/poll.o .libs/signal.o -lnsl -lrt -lc > -Wl,-bnoentry -Wl,-bE:.libs/libevent.exp ${wl}-berok > collect2: library libgcc_s not found > make: 1254-004 The error code from the last command is 1. > > > Stop. > make: 1254-004 The error code from the last command is 1. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > > Does anyone know what this problem is? > > Thanks in advance for any help that can be provided, > > Nick > From liusifan at gmail.com Sat Apr 19 21:50:32 2008 From: liusifan at gmail.com (liusifan) Date: Sat Apr 19 21:50:52 2008 Subject: [Libevent-users] Re: Success compile libevent 1.4.3 with VC6 References: <200804162310435768324@gmail.com> Message-ID: <200804200950240156327@gmail.com> Hi, all The previous MSVC6 project files is for single-threaded. The new projects files is for multi-threaded, please check the attachment. Best regards£¬ liusifan 2008-04-20 >>> >Hi, all > >Compile the following svn version success with VC6. > >https://levent.svn.sourceforge.net/svnroot/levent/tags/release-1.4.3-stable > >Step 1 Add VC6 project files, please check as attachment > >Step 2 Modify WIN32-Code/event-config.h, buffer.c, evutil.h > >diff -r release-1.4.3-stable/libevent/WIN32-Code/event-config.h libevent143/WIN32-Code/event-config.h >53,54c53,56 >< /* Define to 1 if you have the header file. */ >< #define _EVENT_HAVE_INTTYPES_H 1 >--- >> /* Define to 1 if you have the header file. */ >> #if defined(_MSG_VER) && _MSC_VER >= 1300 >> #define _EVENT_HAVE_INTTYPES_H 1 >> #endif >Only in libevent143/: WIN32-VC6 >diff -r release-1.4.3-stable/libevent/buffer.c libevent143/buffer.c >158c158 >< sz = vsnprintf(buffer, space - 1, fmt, aq); >--- >> sz = _vsnprintf(buffer, space - 1, fmt, aq); >diff -r release-1.4.3-stable/libevent/evutil.h libevent143/evutil.h >57c57 >< #elif defined(WIN32) >--- >> #elif defined(WIN32) >59c59,63 >< #define ev_int64_t __int64_t >--- >> #if ( _MSC_VER < 1300 ) >> #define ev_int64_t __int64 >> #else >> #define ev_int64_t __int64_t >> #endif > > >Best Regards, > >Stephen Liu >2008-04-16 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-msvc6.zip Type: application/octet-stream Size: 2292 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20080420/72378e3a/libevent-msvc6.obj From daniminas at gmail.com Tue Apr 22 22:00:29 2008 From: daniminas at gmail.com (Daniel Morales) Date: Tue Apr 22 22:00:48 2008 Subject: [Libevent-users] libevent and autotools Message-ID: Hi all, Since libevent doesn't have a *.pc file to use with pkg-config, i need to add some manual check to a configure.in. Any example for libevent to share? :) Thanks, -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20080422/e5994568/attachment.htm From nickm at freehaven.net Wed Apr 23 00:38:07 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Wed Apr 23 00:38:42 2008 Subject: [Libevent-users] libevent and autotools In-Reply-To: References: Message-ID: <20080423043807.GC24086@moria.seul.org> On Tue, Apr 22, 2008 at 11:00:29PM -0300, Daniel Morales wrote: > Hi all, > > Since libevent doesn't have a *.pc file to use with pkg-config, i need to > add some manual check to a configure.in. Hm! pkg-config! Yes, that's a good idea; we should support that in libevent 2.0 and later. Would you like to write a patch to libevent to add pkg-config support? > Any example for libevent to share? :) You could just search for a header called event.h that defines event_init, and flags like -levent-core that defines event_init. If you want to abuse autoconf and look in a bunch of likely places for the headers and libraries, you could try to see what Tor does, but I'm afraid it's a little baroque. Look in https://www.torproject.org/svn/trunk/configure.in for mention of libevent, and in https://www.torproject.org/svn/trunk/acinclude.m4 for a definition of the TOR_SEARCH_LIBRARY macro. (Yes, this is an ugly and underdocumented hack. Sorry. All of it seemed important at the time.) From hmd at mail.ru Wed Apr 23 09:34:04 2008 From: hmd at mail.ru (Eugene 'HMage' Bujak) Date: Wed Apr 23 09:34:35 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 Message-ID: <480F3ACC.6010102@mail.ru> Hi, I want to submit a more complete patch for VC6. This one makes all elements of the code compilable and this code is being used on a production-level project at work. The patch is in attachment. Compiles and works under VC6. * signal_test works. * timer_test works. * event_test fails due to the reason that win32 select() can't work on anything but network sockets. Most importantly, my code that runs perfectly well on unix (linux & freebsd) now runs on windows with little modification. But: * Didn't try to run any other tests since there are no project files for them. * Didn't test how mingw32 copes with these changes either. The main changes are: * INPUT and OUTPUT are defined in platform SDK, so I had to redefine them as EVRPC_INPUT and EVRPC_OUTPUT. * uint64_t on MSVC must be defined as unsigned __int64 * int64_t on MSVC is to be defined as signed __int64 * MSVC6 doesn't know about __func__ and the #ifdefs weren't guarding against them good enough. * winsock2.h sometimes was included after windows.h, that lead to compiler errors in libevent. * select.c can be painlessly excluded from compilation in win32, but I still fixed it's compilation. * Winsock library needs to be initialized and freed explicitly on win32. * http.c was using sockaddr_storage. There isn't one in MSVC. Using sockaddr is good enough for MSVC. * There are tons of compiler warnings regarding "do {} while(0);" * I took the liberty to add #pragma to the WIN32-section of the event.h so that there's no need to put ws2_32 library into the linker explicitly. * There's no NFDBITS in msvc. * vsnprintf() is _vsnprintf() for some weird reason on win32. * I've had to bump tv->tv_usec to 1000 to prevent eating 100% of the cpu core in win32 dispatch when using timers with events each 10ms or so. * Also I've provided a gettimeofday() wrapper that uses timeGetTime() instead of much slower _ftime(). Also, I would like to ask the maintainer of the project to change svn:eol-style property of .dsw and .dsp files on SVN repository toto CRLF, since project loader handles these files properly only when line endings are in windows style. -- - Eugene 'HMage' Bujak. -------------- next part -------------- diff -ur libevent-1.4.3-stable/WIN32-Code/config.h libevent-1.4.3-stable-win32/WIN32-Code/config.h --- libevent-1.4.3-stable/WIN32-Code/config.h Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Code/config.h Wed Apr 23 17:31:03 2008 @@ -205,8 +205,8 @@ /* Version number of package */ #define VERSION "1.3.99-trunk" -/* Define to appropriate substitue if compiler doesnt have __func__ */ -#if defined(_MSC_VER) && _MSC_VER < 1300 +/* Define to appropriate substitute if compiler doesn't have __func__ */ +#ifdef _MSC_VER #define __func__ "??" #else #define __func__ __FUNCTION__ diff -ur libevent-1.4.3-stable/WIN32-Code/misc.c libevent-1.4.3-stable-win32/WIN32-Code/misc.c --- libevent-1.4.3-stable/WIN32-Code/misc.c Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Code/misc.c Wed Apr 23 17:31:03 2008 @@ -1,9 +1,14 @@ #include #include +#include // winsock2.h must be before windows.h to have any effect #include #include #include +#ifdef _MSC_VER +#pragma comment(lib,"winmm") +#endif + #ifdef __GNUC__ /*our prototypes for timeval and timezone are in here, just in case the above headers don't have them*/ @@ -16,7 +21,7 @@ * * Purpose: Get current time of day. * - * Arguments: tv => Place to store the curent time of day. + * Arguments: tv => Place to store the current time of day. * tz => Ignored. * * Returns: 0 => Success. @@ -24,6 +29,7 @@ ****************************************************************************/ #ifndef HAVE_GETTIMEOFDAY +#ifndef _WIN32 int gettimeofday(struct timeval *tv, struct timezone *tz) { struct _timeb tb; @@ -35,6 +41,21 @@ tv->tv_usec = ((int) tb.millitm) * 1000; return 0; } +#else +struct timezone; +int gettimeofday(struct timeval *tv, struct timezone *tz) { + DWORD ms; + tz; + if(tv == NULL) + return -1; + + ms = timeGetTime(); + tv->tv_sec = ms / 1000;//(long)floor(ms * 0.001); + tv->tv_usec = (ms - (tv->tv_sec*1000))*1000; + + return 0; +} +#endif #endif #if 0 diff -ur libevent-1.4.3-stable/WIN32-Code/win32.c libevent-1.4.3-stable-win32/WIN32-Code/win32.c --- libevent-1.4.3-stable/WIN32-Code/win32.c Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Code/win32.c Wed Apr 23 17:32:04 2008 @@ -32,7 +32,7 @@ #include "../config.h" #endif -#include +#include // winsock2.h must be before windows.h to have any effect #include #include #include @@ -234,6 +234,27 @@ { struct win32op *winop; size_t size; + +#ifdef _WIN32 + WORD wVersionRequested; + WSADATA wsaData; + int retval; + + wVersionRequested = MAKEWORD( 2, 2 ); + + retval = WSAStartup( wVersionRequested, &wsaData ); + if (retval != 0) { + event_err(1, "Couldn't initialize WinSock library.\n"); + return NULL; + } + + if (LOBYTE(wsaData.wVersion) != 2 || HIBYTE(wsaData.wVersion) != 2) { + event_err(1, "WinSock library is not acceptable version.\n"); + return NULL; + } + +#endif + if (!(winop = calloc(1, sizeof(struct win32op)))) return NULL; winop->fd_setsz = NEVENT; @@ -360,11 +381,17 @@ if (!fd_count) { /* Windows doesn't like you to call select() with no sockets */ - Sleep(timeval_to_ms(tv)); + int sleep_ms = timeval_to_ms(tv); + if (sleep_ms <= 0) sleep_ms = 1; + Sleep(sleep_ms); evsignal_process(base); return (0); } + if ((tv) && (tv->tv_usec == 0) && (tv->tv_sec == 0)) { + tv->tv_usec = 1000; + } + res = select(fd_count, (struct fd_set*)win32op->readset_out, (struct fd_set*)win32op->writeset_out, @@ -423,6 +450,8 @@ if (win32op->exset_out) free(win32op->exset_out); /* XXXXX free the tree. */ + + WSACleanup(); memset(win32op, 0, sizeof(win32op)); free(win32op); diff -ur libevent-1.4.3-stable/WIN32-Prj/event_test/event_test.dsp libevent-1.4.3-stable-win32/WIN32-Prj/event_test/event_test.dsp --- libevent-1.4.3-stable/WIN32-Prj/event_test/event_test.dsp Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Prj/event_test/event_test.dsp Wed Apr 23 17:31:03 2008 @@ -39,6 +39,7 @@ # PROP Use_Debug_Libraries 0 # PROP Output_Dir "Release" # PROP Intermediate_Dir "Release" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c # ADD CPP /nologo /W3 /GX /O2 /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c @@ -49,7 +50,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /machine:I386 !ELSEIF "$(CFG)" == "event_test - Win32 Debug" @@ -62,6 +63,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Debug" # PROP Intermediate_Dir "Debug" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c # ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c @@ -72,7 +74,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept !ENDIF diff -ur libevent-1.4.3-stable/WIN32-Prj/libevent.dsp libevent-1.4.3-stable-win32/WIN32-Prj/libevent.dsp --- libevent-1.4.3-stable/WIN32-Prj/libevent.dsp Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Prj/libevent.dsp Wed Apr 23 17:31:03 2008 @@ -41,7 +41,7 @@ # PROP Intermediate_Dir "Release" # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /YX /FD /c -# ADD CPP /nologo /W3 /GX /O2 /I "..\\" /I "..\WIN32-Code" /I "..\compat" /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /YX /FD /c +# ADD CPP /nologo /W3 /GX /O2 /I "..\\" /I "..\WIN32-Code" /I "..\compat" /D "NDEBUG" /D "WIN32" /D "_MBCS" /D "_LIB" /D "HAVE_CONFIG_H" /YX /FD /c # ADD BASE RSC /l 0x409 /d "NDEBUG" # ADD RSC /l 0x409 /d "NDEBUG" BSC32=bscmake.exe @@ -64,7 +64,7 @@ # PROP Intermediate_Dir "Debug" # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c -# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\\" /I "..\WIN32-Code" /I "..\compat" /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c +# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\\" /I "..\WIN32-Code" /I "..\compat" /D "_DEBUG" /D "WIN32" /D "_MBCS" /D "_LIB" /D "HAVE_CONFIG_H" /YX /FD /GZ /c # ADD BASE RSC /l 0x409 /d "_DEBUG" # ADD RSC /l 0x409 /d "_DEBUG" BSC32=bscmake.exe @@ -85,7 +85,11 @@ # PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" # Begin Source File -SOURCE=..\log.c +SOURCE=..\buffer.c +# End Source File +# Begin Source File + +SOURCE=..\evbuffer.c # End Source File # Begin Source File @@ -93,10 +97,38 @@ # End Source File # Begin Source File +SOURCE=..\event_tagging.c +# End Source File +# Begin Source File + +SOURCE=..\evrpc.c +# End Source File +# Begin Source File + +SOURCE=..\evutil.c +# End Source File +# Begin Source File + +SOURCE=..\log.c +# End Source File +# Begin Source File + SOURCE="..\WIN32-Code\misc.c" # End Source File # Begin Source File +SOURCE=..\select.c +# End Source File +# Begin Source File + +SOURCE=..\signal.c +# End Source File +# Begin Source File + +SOURCE=..\strlcpy.c +# End Source File +# Begin Source File + SOURCE="..\WIN32-Code\win32.c" # End Source File # End Group @@ -117,11 +149,59 @@ # End Source File # Begin Source File +SOURCE=..\evdns.h +# End Source File +# Begin Source File + +SOURCE="..\event-config.h" +# End Source File +# Begin Source File + +SOURCE="..\event-internal.h" +# End Source File +# Begin Source File + SOURCE=..\event.h # End Source File # Begin Source File +SOURCE=..\evhttp.h +# End Source File +# Begin Source File + +SOURCE="..\evrpc-internal.h" +# End Source File +# Begin Source File + +SOURCE=..\evrpc.h +# End Source File +# Begin Source File + +SOURCE=..\evsignal.h +# End Source File +# Begin Source File + +SOURCE=..\evutil.h +# End Source File +# Begin Source File + +SOURCE="..\http-internal.h" +# End Source File +# Begin Source File + +SOURCE=..\log.h +# End Source File +# Begin Source File + +SOURCE=..\min_heap.h +# End Source File +# Begin Source File + SOURCE="..\WIN32-Code\misc.h" +# End Source File +# Begin Source File + +SOURCE="..\strlcpy-internal.h" # End Source File # End Group # End Target diff -ur libevent-1.4.3-stable/WIN32-Prj/signal_test/signal_test.dsp libevent-1.4.3-stable-win32/WIN32-Prj/signal_test/signal_test.dsp --- libevent-1.4.3-stable/WIN32-Prj/signal_test/signal_test.dsp Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Prj/signal_test/signal_test.dsp Wed Apr 23 17:31:03 2008 @@ -39,17 +39,18 @@ # PROP Use_Debug_Libraries 0 # PROP Output_Dir "Release" # PROP Intermediate_Dir "Release" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c -# ADD CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c +# ADD CPP /nologo /W3 /GX /O2 /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c # ADD BASE RSC /l 0x409 /d "NDEBUG" # ADD RSC /l 0x409 /d "NDEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe -# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /machine:I386 !ELSEIF "$(CFG)" == "signal_test - Win32 Debug" @@ -62,17 +63,18 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Debug" # PROP Intermediate_Dir "Debug" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" -# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c -# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c +# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c +# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c # ADD BASE RSC /l 0x409 /d "_DEBUG" # ADD RSC /l 0x409 /d "_DEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe -# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept !ENDIF diff -ur libevent-1.4.3-stable/WIN32-Prj/time_test/time_test.dsp libevent-1.4.3-stable-win32/WIN32-Prj/time_test/time_test.dsp --- libevent-1.4.3-stable/WIN32-Prj/time_test/time_test.dsp Wed Apr 23 17:31:16 2008 +++ libevent-1.4.3-stable-win32/WIN32-Prj/time_test/time_test.dsp Wed Apr 23 17:31:03 2008 @@ -39,17 +39,18 @@ # PROP Use_Debug_Libraries 0 # PROP Output_Dir "Release" # PROP Intermediate_Dir "Release" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c -# ADD CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c +# ADD CPP /nologo /W3 /GX /O2 /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /c # ADD BASE RSC /l 0x409 /d "NDEBUG" # ADD RSC /l 0x409 /d "NDEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe -# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /machine:I386 +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /machine:I386 !ELSEIF "$(CFG)" == "time_test - Win32 Debug" @@ -62,17 +63,18 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Debug" # PROP Intermediate_Dir "Debug" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" -# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c -# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c +# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c +# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "..\..\\" /I "..\..\WIN32-Code" /I "..\..\compat" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c # ADD BASE RSC /l 0x409 /d "_DEBUG" # ADD RSC /l 0x409 /d "_DEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe -# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD LINK32 ws2_32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept !ENDIF diff -ur libevent-1.4.3-stable/buffer.c libevent-1.4.3-stable-win32/buffer.c --- libevent-1.4.3-stable/buffer.c Wed Apr 23 17:31:13 2008 +++ libevent-1.4.3-stable-win32/buffer.c Wed Apr 23 17:31:00 2008 @@ -30,7 +30,7 @@ #endif #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #endif @@ -155,7 +155,7 @@ va_copy(aq, ap); #ifdef WIN32 - sz = vsnprintf(buffer, space - 1, fmt, aq); + sz = _vsnprintf(buffer, space - 1, fmt, aq); buffer[space - 1] = '\0'; #else sz = vsnprintf(buffer, space, fmt, aq); diff -ur libevent-1.4.3-stable/compat/sys/_time.h libevent-1.4.3-stable-win32/compat/sys/_time.h --- libevent-1.4.3-stable/compat/sys/_time.h Wed Apr 23 17:31:13 2008 +++ libevent-1.4.3-stable-win32/compat/sys/_time.h Wed Apr 23 17:31:01 2008 @@ -41,10 +41,12 @@ * Structure returned by gettimeofday(2) system call, * and used in other calls. */ +#ifndef _MSC_VER // MSVC defines this in winsock2.h struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; +#endif /* * Structure defined by POSIX.1b to be like a timeval. @@ -78,10 +80,12 @@ /* Operations on timevals. */ #define timerclear(tvp) (tvp)->tv_sec = (tvp)->tv_usec = 0 #define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec) +#ifndef _MSC_VER // MSVC defines this in winsock2.h #define timercmp(tvp, uvp, cmp) \ (((tvp)->tv_sec == (uvp)->tv_sec) ? \ ((tvp)->tv_usec cmp (uvp)->tv_usec) : \ ((tvp)->tv_sec cmp (uvp)->tv_sec)) +#endif #define timeradd(tvp, uvp, vvp) \ do { \ (vvp)->tv_sec = (tvp)->tv_sec + (uvp)->tv_sec; \ diff -ur libevent-1.4.3-stable/evdns.c libevent-1.4.3-stable-win32/evdns.c --- libevent-1.4.3-stable/evdns.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evdns.c Wed Apr 23 17:31:01 2008 @@ -105,7 +105,7 @@ #include "evutil.h" #include "log.h" #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #include #include diff -ur libevent-1.4.3-stable/event-config.h libevent-1.4.3-stable-win32/event-config.h --- libevent-1.4.3-stable/event-config.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/event-config.h Wed Apr 23 17:31:01 2008 @@ -51,7 +51,9 @@ #define _EVENT_HAVE_INET_NTOP 1 /* Define to 1 if you have the header file. */ +#ifndef _MSC_VER // MSVC doesn't have that #define _EVENT_HAVE_INTTYPES_H 1 +#endif /* Define to 1 if you have the `kqueue' function. */ #define _EVENT_HAVE_KQUEUE 1 @@ -105,7 +107,9 @@ #define _EVENT_HAVE_STDARG_H 1 /* Define to 1 if you have the header file. */ +#ifndef _MSC_VER // MSVC doesn't have that #define _EVENT_HAVE_STDINT_H 1 +#endif /* Define to 1 if you have the header file. */ #define _EVENT_HAVE_STDLIB_H 1 @@ -159,7 +163,9 @@ #define _EVENT_HAVE_SYS_STAT_H 1 /* Define to 1 if you have the header file. */ +#ifndef _MSC_VER // MSVC doesn't have that #define _EVENT_HAVE_SYS_TIME_H 1 +#endif /* Define to 1 if you have the header file. */ #define _EVENT_HAVE_SYS_TYPES_H 1 @@ -183,10 +189,14 @@ #define _EVENT_HAVE_UINT16_T 1 /* Define to 1 if the system has the type `uint32_t'. */ +#ifndef _MSC_VER // MSVC doesn't have that #define _EVENT_HAVE_UINT32_T 1 +#endif /* Define to 1 if the system has the type `uint64_t'. */ +#ifndef _MSC_VER // MSVC doesn't have that #define _EVENT_HAVE_UINT64_T 1 +#endif /* Define to 1 if the system has the type `uint8_t'. */ #define _EVENT_HAVE_UINT8_T 1 diff -ur libevent-1.4.3-stable/event-internal.h libevent-1.4.3-stable-win32/event-internal.h --- libevent-1.4.3-stable/event-internal.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/event-internal.h Wed Apr 23 17:31:01 2008 @@ -31,6 +31,13 @@ extern "C" { #endif +#ifdef _WIN32 // MSVC doesn't have that +#ifndef NFDBITS +typedef long int fd_mask; +#define NFDBITS (8 * sizeof(fd_mask)) +#endif +#endif + #include "config.h" #include "min_heap.h" #include "evsignal.h" diff -ur libevent-1.4.3-stable/event.c libevent-1.4.3-stable-win32/event.c --- libevent-1.4.3-stable/event.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/event.c Wed Apr 23 17:31:01 2008 @@ -30,6 +30,7 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include #undef WIN32_LEAN_AND_MEAN #include "misc.h" diff -ur libevent-1.4.3-stable/event.h libevent-1.4.3-stable-win32/event.h --- libevent-1.4.3-stable/event.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/event.h Wed Apr 23 17:31:01 2008 @@ -176,7 +176,9 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include +#pragma comment(lib,"ws2_32") // automatically link ws2_32 library on Win32 #undef WIN32_LEAN_AND_MEAN typedef unsigned char u_char; typedef unsigned short u_short; diff -ur libevent-1.4.3-stable/event_tagging.c libevent-1.4.3-stable-win32/event_tagging.c --- libevent-1.4.3-stable/event_tagging.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/event_tagging.c Wed Apr 23 17:31:01 2008 @@ -38,7 +38,7 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN -#include +#include // winsock2.h must be before windows.h to have any effect #include #undef WIN32_LEAN_AND_MEAN #else diff -ur libevent-1.4.3-stable/evhttp.h libevent-1.4.3-stable-win32/evhttp.h --- libevent-1.4.3-stable/evhttp.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evhttp.h Wed Apr 23 17:31:01 2008 @@ -35,8 +35,8 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include -#include #undef WIN32_LEAN_AND_MEAN #endif diff -ur libevent-1.4.3-stable/evrpc.c libevent-1.4.3-stable-win32/evrpc.c --- libevent-1.4.3-stable/evrpc.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evrpc.c Wed Apr 23 17:31:01 2008 @@ -30,8 +30,8 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include -#include #undef WIN32_LEAN_AND_MEAN #include "misc.h" #endif @@ -89,10 +89,10 @@ assert(evrpc_unregister_rpc(base, rpc->uri)); } while ((hook = TAILQ_FIRST(&base->input_hooks)) != NULL) { - assert(evrpc_remove_hook(base, INPUT, hook)); + assert(evrpc_remove_hook(base, EVRPC_INPUT, hook)); } while ((hook = TAILQ_FIRST(&base->output_hooks)) != NULL) { - assert(evrpc_remove_hook(base, OUTPUT, hook)); + assert(evrpc_remove_hook(base, EVRPC_OUTPUT, hook)); } free(base); } @@ -107,14 +107,14 @@ struct evrpc_hook_list *head = NULL; struct evrpc_hook *hook = NULL; switch (hook_type) { - case INPUT: + case EVRPC_INPUT: head = &base->in_hooks; break; - case OUTPUT: + case EVRPC_OUTPUT: head = &base->out_hooks; break; default: - assert(hook_type == INPUT || hook_type == OUTPUT); + assert(hook_type == EVRPC_INPUT || hook_type == EVRPC_OUTPUT); } hook = calloc(1, sizeof(struct evrpc_hook)); @@ -152,14 +152,14 @@ struct _evrpc_hooks *base = vbase; struct evrpc_hook_list *head = NULL; switch (hook_type) { - case INPUT: + case EVRPC_INPUT: head = &base->in_hooks; break; - case OUTPUT: + case EVRPC_OUTPUT: head = &base->out_hooks; break; default: - assert(hook_type == INPUT || hook_type == OUTPUT); + assert(hook_type == EVRPC_INPUT || hook_type == EVRPC_OUTPUT); } return (evrpc_remove_hook_internal(head, handle)); @@ -425,11 +425,11 @@ } while ((hook = TAILQ_FIRST(&pool->input_hooks)) != NULL) { - assert(evrpc_remove_hook(pool, INPUT, hook)); + assert(evrpc_remove_hook(pool, EVRPC_INPUT, hook)); } while ((hook = TAILQ_FIRST(&pool->output_hooks)) != NULL) { - assert(evrpc_remove_hook(pool, OUTPUT, hook)); + assert(evrpc_remove_hook(pool, EVRPC_OUTPUT, hook)); } free(pool); diff -ur libevent-1.4.3-stable/evrpc.h libevent-1.4.3-stable-win32/evrpc.h --- libevent-1.4.3-stable/evrpc.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evrpc.h Wed Apr 23 17:31:01 2008 @@ -436,8 +436,8 @@ */ enum EVRPC_HOOK_TYPE { - INPUT, /**< apply the function to an input hook */ - OUTPUT /**< apply the function to an output hook */ + EVRPC_INPUT, /**< apply the function to an input hook */ + EVRPC_OUTPUT /**< apply the function to an output hook */ }; /** adds a processing hook to either an rpc base or rpc pool diff -ur libevent-1.4.3-stable/evutil.c libevent-1.4.3-stable-win32/evutil.c --- libevent-1.4.3-stable/evutil.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evutil.c Wed Apr 23 17:31:01 2008 @@ -30,9 +30,10 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include +#include // for _atoi64() #undef WIN32_LEAN_AND_MEAN -#include #include "misc.h" #endif diff -ur libevent-1.4.3-stable/evutil.h libevent-1.4.3-stable-win32/evutil.h --- libevent-1.4.3-stable/evutil.h Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/evutil.h Wed Apr 23 17:31:01 2008 @@ -55,8 +55,8 @@ #define ev_uint64_t uint64_t #define ev_int64_t int64_t #elif defined(WIN32) -#define ev_uint64_t __uint64_t -#define ev_int64_t __int64_t +#define ev_uint64_t unsigned __int64 +#define ev_int64_t signed __int64 #elif _EVENT_SIZEOF_LONG_LONG == 8 #define ev_uint64_t unsigned long long #define ev_int64_t long long diff -ur libevent-1.4.3-stable/http.c libevent-1.4.3-stable-win32/http.c --- libevent-1.4.3-stable/http.c Wed Apr 23 17:31:14 2008 +++ libevent-1.4.3-stable-win32/http.c Wed Apr 23 17:31:02 2008 @@ -1982,7 +1982,12 @@ accept_socket(int fd, short what, void *arg) { struct evhttp *http = arg; +#ifndef _MSC_VER struct sockaddr_storage ss; +#else + // MSVC doesn't have sockaddr_storage + struct sockaddr ss; +#endif socklen_t addrlen = sizeof(ss); int nfd; diff -ur libevent-1.4.3-stable/log.c libevent-1.4.3-stable-win32/log.c --- libevent-1.4.3-stable/log.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/log.c Wed Apr 23 17:31:02 2008 @@ -43,6 +43,7 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include #undef WIN32_LEAN_AND_MEAN #include "misc.h" diff -ur libevent-1.4.3-stable/sample/event-test.c libevent-1.4.3-stable-win32/sample/event-test.c --- libevent-1.4.3-stable/sample/event-test.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/sample/event-test.c Wed Apr 23 17:31:02 2008 @@ -14,6 +14,7 @@ #include #include #else +#include // winsock2.h must be before windows.h to have any effect #include #endif #include diff -ur libevent-1.4.3-stable/sample/signal-test.c libevent-1.4.3-stable-win32/sample/signal-test.c --- libevent-1.4.3-stable/sample/signal-test.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/sample/signal-test.c Wed Apr 23 17:31:02 2008 @@ -15,6 +15,7 @@ #include #include #else +#include // winsock2.h must be before windows.h to have any effect #include #endif #include @@ -33,7 +34,7 @@ { struct event *signal = arg; - printf("%s: got signal %d\n", __func__, EVENT_SIGNAL(signal)); + printf("%s: got signal %d\n", "signal_cb", EVENT_SIGNAL(signal)); if (called >= 2) event_del(signal); diff -ur libevent-1.4.3-stable/sample/time-test.c libevent-1.4.3-stable-win32/sample/time-test.c --- libevent-1.4.3-stable/sample/time-test.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/sample/time-test.c Wed Apr 23 17:31:02 2008 @@ -36,7 +36,7 @@ struct event *timeout = arg; int newtime = time(NULL); - printf("%s: called at %d: %d\n", __func__, newtime, + printf("%s: called at %d: %d\n", "timeout_cb", newtime, newtime - lasttime); lasttime = newtime; @@ -51,7 +51,7 @@ struct event timeout; struct timeval tv; - /* Initalize the event library */ + /* Initialize the event library */ event_init(); /* Initalize one event */ diff -ur libevent-1.4.3-stable/select.c libevent-1.4.3-stable-win32/select.c --- libevent-1.4.3-stable/select.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/select.c Wed Apr 23 17:31:02 2008 @@ -30,6 +30,12 @@ #include "config.h" #endif +#ifdef _WIN32 +#define WIN32_LEAN_AND_MEAN +#include +#include +#endif // _WIN32 + #include #ifdef HAVE_SYS_TIME_H #include @@ -44,7 +50,9 @@ #include #include #include +#ifndef _MSC_VER // MSVC doesn't have this #include +#endif #include #ifdef CHECK_INVARIANTS #include diff -ur libevent-1.4.3-stable/signal.c libevent-1.4.3-stable-win32/signal.c --- libevent-1.4.3-stable/signal.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/signal.c Wed Apr 23 17:31:02 2008 @@ -32,8 +32,8 @@ #ifdef WIN32 #define WIN32_LEAN_AND_MEAN +#include // winsock2.h must be before windows.h to have any effect #include -#include #undef WIN32_LEAN_AND_MEAN #endif #include diff -ur libevent-1.4.3-stable/test/bench.c libevent-1.4.3-stable-win32/test/bench.c --- libevent-1.4.3-stable/test/bench.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/test/bench.c Wed Apr 23 17:31:02 2008 @@ -41,6 +41,7 @@ #include #include #ifdef WIN32 +#include // winsock2.h must be before windows.h to have any effect #include #else #include diff -ur libevent-1.4.3-stable/test/regress.c libevent-1.4.3-stable-win32/test/regress.c --- libevent-1.4.3-stable/test/regress.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/test/regress.c Wed Apr 23 17:31:02 2008 @@ -26,7 +26,7 @@ */ #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #endif diff -ur libevent-1.4.3-stable/test/regress_dns.c libevent-1.4.3-stable-win32/test/regress_dns.c --- libevent-1.4.3-stable/test/regress_dns.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/test/regress_dns.c Wed Apr 23 17:31:02 2008 @@ -26,7 +26,7 @@ */ #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #endif diff -ur libevent-1.4.3-stable/test/regress_http.c libevent-1.4.3-stable-win32/test/regress_http.c --- libevent-1.4.3-stable/test/regress_http.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/test/regress_http.c Wed Apr 23 17:31:02 2008 @@ -26,7 +26,7 @@ */ #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #endif diff -ur libevent-1.4.3-stable/test/regress_rpc.c libevent-1.4.3-stable-win32/test/regress_rpc.c --- libevent-1.4.3-stable/test/regress_rpc.c Wed Apr 23 17:31:15 2008 +++ libevent-1.4.3-stable-win32/test/regress_rpc.c Wed Apr 23 17:31:02 2008 @@ -26,7 +26,7 @@ */ #ifdef WIN32 -#include +#include // winsock2.h must be before windows.h to have any effect #include #endif @@ -450,14 +450,14 @@ need_input_hook = 1; need_output_hook = 1; - assert(evrpc_add_hook(base, INPUT, rpc_hook_add_header, (void*)"input") + assert(evrpc_add_hook(base, EVRPC_INPUT, rpc_hook_add_header, (void*)"input") != NULL); - assert(evrpc_add_hook(base, OUTPUT, rpc_hook_add_header, (void*)"output") + assert(evrpc_add_hook(base, EVRPC_OUTPUT, rpc_hook_add_header, (void*)"output") != NULL); pool = rpc_pool_with_connection(port); - assert(evrpc_add_hook(pool, INPUT, rpc_hook_remove_header, (void*)"output")); + assert(evrpc_add_hook(pool, EVRPC_INPUT, rpc_hook_remove_header, (void*)"output")); /* set up the basic message */ msg = msg_new(); From nickm at freehaven.net Wed Apr 23 19:37:32 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Wed Apr 23 19:38:20 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 In-Reply-To: <480F3ACC.6010102@mail.ru> References: <480F3ACC.6010102@mail.ru> Message-ID: <20080423233732.GB23700@moria.seul.org> On Wed, Apr 23, 2008 at 05:34:04PM +0400, Eugene 'HMage' Bujak wrote: > Hi, > > I want to submit a more complete patch for VC6. > > This one makes all elements of the code compilable and this code is > being used on a production-level project at work. > > The patch is in attachment. Compiles and works under VC6. > * signal_test works. > * timer_test works. > * event_test fails due to the reason that win32 select() can't work on > anything but network sockets. Thanks for the patch; it's good stuff! I'd like to apply it, but there are a few small issues or things that could be done better in order to work well on *non*-vc6 projects. > * INPUT and OUTPUT are defined in platform SDK, so I had to redefine > them as EVRPC_INPUT and EVRPC_OUTPUT. We can't do this change in mainline libevent; it'll break all existing evprc users that use the old names. Maybe there's some way we we can make the old names available on non-vc code, but deprecated in favor of the EVRPC names? something like this: enum EVRPC_HOOK_TYPE { EVRPC_INPUT, EVPRC_OUTPUT, }; #ifndef _WIN32 #define INPUT EVRPC_INPUT #define OUTPUT EVRPC_OUTPUT #endif [...] > * Winsock library needs to be initialized and freed explicitly on win32. This is true, but it's not libevent's job to do it. If we make this change so that libevent starts initializing winsock, we'll break all existing programs that use libevent and know to initialize winsock themselves. It's quite reasonable to call some sockets code before calling event_init, but this part of the patch makes that result in double-initializing winsock. Also, I think this change will double-initialize winsock on all programs that use multiple event bases, and double-shutdown winsock whenever the bases are closed on those programs. [...] > -/* Define to appropriate substitue if compiler doesnt have __func__ */ > -#if defined(_MSC_VER) && _MSC_VER < 1300 > +/* Define to appropriate substitute if compiler doesn't have __func__ */ > +#ifdef _MSC_VER > #define __func__ "??" I thought some versions of VC *did* have an acceptable version of __func__ or a replacement for it. If that's true, this will break those other VCs. What is _MSC_VER defined to on VC6? Should the test be something other than _MSC_VER < 1300? > diff -ur libevent-1.4.3-stable/event-config.h libevent-1.4.3-stable-win32/event-config.h > --- libevent-1.4.3-stable/event-config.h Wed Apr 23 17:31:14 2008 > +++ libevent-1.4.3-stable-win32/event-config.h Wed Apr 23 17:31:01 2008 > @@ -51,7 +51,9 @@ > #define _EVENT_HAVE_INET_NTOP 1 > > /* Define to 1 if you have the header file. */ > +#ifndef _MSC_VER // MSVC doesn't have that > #define _EVENT_HAVE_INTTYPES_H 1 > +#endif This approach is the wrong way to make event-config.h work. On all toolsets besides VC, the file is automatically generated from config.h, which itself is automatically generated by the autoconf script. The right approach for VC is just to have a separate config.h and event-config.h script that work, ideally in the WIN32-Code directory, and set up the compiler's search path so those get used instead of any other ones that might be kicking around. [...] > +#ifdef _WIN32 // MSVC doesn't have that FWIW, many older C compilers don't allow C++-style comments: they weren't added to the C standard till the C99 standard. We need libevent to build on older compilers, so we can't add C++-style comments to libevent. Otherwise, though, this looks like solid work, and I'm quite glad that somebody has a copy of VC6 and the willingness to do it! If you can send in a revised patch, that'd be great. Otherwise, I'll try to hand-apply it with modifications as noted above, but since my x86 box is down at the moment, I can't fire up windows to test it out now, and things might go badly. many thanks, -- Nick Mathewson From james at mansionfamily.plus.com Sun Apr 27 09:01:44 2008 From: james at mansionfamily.plus.com (James Mansion) Date: Sun Apr 27 08:59:00 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 In-Reply-To: <20080423233732.GB23700@moria.seul.org> References: <480F3ACC.6010102@mail.ru> <20080423233732.GB23700@moria.seul.org> Message-ID: <48147938.204@mansionfamily.plus.com> > Also, I think this change will double-initialize winsock on all > programs that use multiple event bases, and double-shutdown winsock > whenever the bases are closed on those programs. > From the MSDN docs: An application can call *WSAStartup* more than once if it needs to obtain the *WSADATA* structure information more than once. On each such call, the application can specify any version number supported by the Winsock DLL. An application must call the *WSACleanup* function for every successful time the *WSAStartup* function is called. From Bob.Maccione at hilton.com Sun Apr 27 16:12:24 2008 From: Bob.Maccione at hilton.com (Bob Maccione) Date: Sun Apr 27 16:27:53 2008 Subject: [Libevent-users] garbage collection in libevent Message-ID: Hi all, I'm looking to try to use the C based garbage collection package at http://www.hpl.hp.com/personal/Hans_Boehm/gc/, integrating into my code is prety easy but I'm not sure what's needed to change libevent to also use the same package (since I'm getting errors when I change my mallocs to GC_MALLOC, in a weird place -- >[err] event_queue_remove: 12ff8c(fd 0) not on queue 1. I'm going to give it a try to replace the malloc's with GC_MALLOC first and no-op the free's to see how it works... Anybody been down this path? thanks bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20080427/d72b6b22/attachment.htm From provos at citi.umich.edu Sun Apr 27 16:34:12 2008 From: provos at citi.umich.edu (Niels Provos) Date: Sun Apr 27 16:34:15 2008 Subject: [Libevent-users] garbage collection in libevent In-Reply-To: References: Message-ID: <850f7cbe0804271334w6652bbb8pc8770446b5c1e4db@mail.gmail.com> On Sun, Apr 27, 2008 at 1:12 PM, Bob Maccione wrote: > Hi all, I'm looking to try to use the C based garbage collection package at > http://www.hpl.hp.com/personal/Hans_Boehm/gc/, integrating into my code is > prety easy but I'm not sure what's needed to change libevent to also use the > same package (since I'm getting errors when I change my mallocs to > GC_MALLOC, in a weird place -- >[err] event_queue_remove: 12ff8c(fd 0) not > on queue 1. You could try to use event_set_mem_functions() to change the functions that libevent uses for memory allocation internally. Niels. From nickm at freehaven.net Tue Apr 29 13:52:25 2008 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Apr 29 13:53:34 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 In-Reply-To: <48147938.204@mansionfamily.plus.com> References: <480F3ACC.6010102@mail.ru> <20080423233732.GB23700@moria.seul.org> <48147938.204@mansionfamily.plus.com> Message-ID: <20080429175225.GH23700@moria.seul.org> On Sun, Apr 27, 2008 at 02:01:44PM +0100, James Mansion wrote: > > >Also, I think this change will double-initialize winsock on all > >programs that use multiple event bases, and double-shutdown winsock > >whenever the bases are closed on those programs. > > > From the MSDN docs: > > An application can call *WSAStartup* more than once if it needs to > obtain the *WSADATA* structure information more than once. On each such > call, the application can specify any version number supported by the > Winsock DLL. > > An application must call the *WSACleanup* function for every successful > time the *WSAStartup* function is called. Ah! Never mind that part of my message then. If this is so, I see no reason not to add a WSAStartup call. yrs, -- Nick From dan at sunsaturn.com Tue Apr 29 22:27:21 2008 From: dan at sunsaturn.com (Dan) Date: Tue Apr 29 22:35:04 2008 Subject: [Libevent-users] first post In-Reply-To: References: Message-ID: Hi been working with your library for abit now, just under the Lib::Event perl module.... I ran into something and was wondering if it has to do with perl module or c library its linked against.... event_new($childtoparent,EV_WRITE,\&myfunction)->add(); event_new($childtoparent,EV_WRITE,\&myfunction)->add(); event_mainloop(); Now what happens is it will just hang it seems because I added 2 or more write events on same filehandle. It only works if I only use 1. Well maybe I'd like to do something like print "blah blah blah"; to the socket/pipe then on second round do print "blah blah blah\r\n"; This is a pipe created with socketpair. I tested it the other way around using EV_READ and I could put say: event_new($parenttochild,EV_READ,\&myfunction)->add(); event_new($parenttochild,EV_READ,\&myfunction)->add(); event_new($parenttochild,EV_READ,\&myfunction)->add(); event_mainloop(); there as many times as i wanted with no hangups. The hangup is in the write select itself on the pipe as it never gets to the function unless I specify a timeout for it....not sure if this is a bug or not. I've tried on linux , freebsd with select,kqueue etc with all the same results. As my first post to list, wanted to say thankyou for your time and patience. Dan. From blibbet at gmail.com Wed Apr 30 08:59:21 2008 From: blibbet at gmail.com (Lee Fisher) Date: Wed Apr 30 09:03:58 2008 Subject: [Libevent-users] Success compile libevent 1.4.3 with VC6 In-Reply-To: <20080423233732.GB23700@moria.seul.org> References: <480F3ACC.6010102@mail.ru> <20080423233732.GB23700@moria.seul.org> Message-ID: <48186D29.3020105@gmail.com> || -#if defined(_MSC_VER) && _MSC_VER < 1300 || +#ifdef _MSC_VER || #define __func__ "??" | | I thought some versions of VC *did* have an acceptable version of | __func__ or a replacement for it. Yes, __FUNCTION__, as libevent already uses. | What is _MSC_VER defined to on VC6? 1200. _MSC_VER 1200: MSC 12.0, VC 6.0, VS 1998 _MSC_VER 1300: MSC 13.0, VC 7.0, VS 2002 _MSC_VER 1310: MSC 13.1, VC 7.1, VS 2003 _MSC_VER 1400: MSC 14.0, VC 8.0, VS 2005 _MSC_VER 1500: MSC 15.0, VC 9.0, VS 2008 http://predef.sourceforge.net/precomp.html | Should the test be something other than _MSC_VER < 1300? I'm not sure when MSC first added __FUNCTION__ support. It is present in VS2005. The below 'WinCE 5.0 Platform Builder' MSDN excerpt seems to agree with your current (pre-patch) test: ----snip---- The new compiler includes the _FUNCTION_ predefined macro. For backward compatible code, add the following definition: #if _MSC_VER < 1300 #define __FUNCTION__ "" #endif ----snip----