From wouter at nlnetlabs.nl Sat Dec 1 06:54:23 2007 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Sat Dec 1 06:54:45 2007 Subject: [Libevent-users] DNS Experiences/Wisdom In-Reply-To: <20071201001925.GA16858@wilbur.25thandClement.com> References: <20071201001925.GA16858@wilbur.25thandClement.com> Message-ID: <47514B6F.3090609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi William, I can tell you some of my experiences, since I am writing my own validator/recursor library and server (using libevent) called _unbound_. So we share a lot of interests :-). ( http://unbound.net ) Unbound is in a beta stage now and works well with DNSSEC/EDNS/NSEC3/ etc. I am only just building a library interface to it. It consists of elegant modules, which are restartable state machines. I intend to expose async validation/recursion interfaces and dnssec information (for all types). So, it is pretty near to what you are saying. (with BSD license instead of the X11 license that you use, it is also a high performance DNS caching validating recursive server). EDNS1 standard is not specified at this time. The RFCs only document EDNS0. Therefore nothing implements it. I think NSEC3 support is going to be important; it is in the final stages of standardization, and several TLDs have implied they are looking to use it. Have you seen the ldns DNS library, at http://nlnetlabs.nl/ldns which is a BSD-licensed handy dandy library for all sorts of DNS tasks (but not a resolver or validator itself)? Tasks like, check signature on record, parse zone file, ... Anyway, apart from this which may help you I am also interested in API and infrastructure requirements that other people have. Best regards, Wouter William Ahern wrote: > I decided to have a go at writing a DNS library from scratch. All of the > libraries I've seen simply mimic the original BSD interfaces (mostly just > gethostbyname(), and BIND's libresolv. > > But, I extensively use record types like SRV, AAAA and TXT, and also am > keenly interested in exposing DNSSEC infrastructure. And things like > client-side caching and easier parameterization are nice, as well as Win32 > compatability without any build gymnastics. And recursive resolution is a > long-term goal, as well. Does anybody know whether EDNS1 has been > implemented anywhere? > > However, I'm not trying to peddle my software, not now at least. Rather, I'm > interested in unconventional uses and requirements, both at the > infrastructure level, and _especially_ API preferences. This is largely > self-serving, because the more feedback I get the better I can > "future-proof" it for my own needs; but I release under an X11-style > license, anyhow. Please send me stories, comments, suggestions, and wishes. > > Of course, this library will plug into libevent at some level, so the > outline of the API is somewhat circumscribed by the async pattern. Usually, > though, I like to design these things as restartable state machines, and > then build a light wrapper around that, because its always nice to be able > to use the core functionality in a small program or in a language binding > without any hassles like non-blocking I/O. > > Current code is in dns.[ch] from a snapshot tarball of libevnet: > > http://25thandclement.com/~william/projects/snapshots/libevnet-snapshot.tgz > > I haven't worked on any I/O interfaces yet, nor the myriad layers which will > go above this, just a DNS query message parser. I've kinda gone crazy with > memory optimizations and making things amenable to compile-time > folding/inlining, particularly because message manipulations will be the > most memory intensive aspect of a resolver given the relative number of > dynamic allocations. So, for instance, the type mask is a bit array, rather > than a bit field, so it can handle the full range of values allowed by the > spec, but with -O1 optimization and constant class and type specificiers GCC > is able to precompute the object entirely. (Well, at least with some > additional macro tricks I haven't committed yet; GCC drops out of its > function inliner when faced with variable argument accesses. I'm still > debating whether to go that extra mile.) > > But, I hope I have preserved a very use friendly interface, and hidden the > complexity. And really its the interface which is most important. > > Here's my regression code, which uses all of the public interfaces so far. > I've snipped out error checking, which is extensive in the library > (including integer overflow checks). > > #include > #include > #include > > int main(void) { > struct dns_message *m = dns_m_open(&dns_defaults); > unsigned char pkt[4096]; > size_t len; > struct dns_m_rr *rr; > > /* #!/usr/bin/perl > * > * use Net::DNS; > * > * my $res = Net::DNS::Resolver->new; > * my $so = $res->bgsend(shift @ARGV || "google.com"); > * > * print $res->bgread($so)->data; > */ > len = fread(pkt, 1, sizeof pkt, stdin); > > dns_m_parse(&m, pkt, len, DNS_M_PARSE_FLUSH)); > > fprintf(stderr, "id:%hu q:%hu ans:%hu add:%hu auth:%hu\n", m->id, m->question.count, m->answers.count, m->authority.count, m->additional.count); > > DNS_M_RR_FOREACH(rr, m, DNS_M_SECTION_ANY, DNS_RR_CLASS(DNS_RR_C_IN), DNS_RR_TYPES(DNS_RR_T_A, DNS_RR_T_TXT, DNS_RR_T_NS)) { > char name[256], rdata[256]; > struct dns_m_txt txt; > > dns_m_dn_expand(m, name, sizeof name, rr->name.base); > > switch (rr->type) { > case DNS_RR_T_TXT: > dns_m_txt_parse(m, &txt, rr); > > dns_m_txt_print(m, rdata, sizeof rdata, &txt, DNS_M_TXT_CONCAT); > > fprintf(stderr, "%s type:%d class:%d ttl:%d rdata:(%u) '%s'\n", name, rr->type, rr->class, rr->ttl, txt.count, rdata); > > break; > default: > fprintf(stderr, "%s type:%d class:%d ttl:%d rdata:%d\n", name, rr->type, rr->class, rr->ttl, rr->rdata.len); > } > } > > return 0; > } /* main() */ > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUUtvkDLqNwOhpPgRAvg+AJ9QG16KBXNi5TB628/+ow7/iba17gCgk4j2 tsc04qAM3HDWFJIE/QY4fF8= =B2pp -----END PGP SIGNATURE----- From invite+ar5egywr at facebookmail.com Fri Dec 7 00:03:03 2007 From: invite+ar5egywr at facebookmail.com (Egg Jacky) Date: Fri Dec 7 00:03:12 2007 Subject: [Libevent-users] Check out my Facebook profile Message-ID: <232d1e1ea71aea232645724244d4b8d5@register.facebook.com> I set up a Facebook profile with my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Egg Here's the link: http://www.facebook.com/p.php?i=835123808&k=4ZG6QWP44WTO3FLESJVT&r&v=2 ___________________ This e-mail may contain promotional materials. If you do not wish to receive future commercial mailings from Facebook, please click on the link below. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. http://www.facebook.com/o.php?u=834852898&k=6a162f -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071206/f48d5992/attachment.htm From libev at schmorp.de Fri Dec 7 15:22:47 2007 From: libev at schmorp.de (Marc Lehmann) Date: Fri Dec 7 15:22:50 2007 Subject: [Libevent-users] libev-1.7 release Message-ID: <20071207202246.GA27686@schmorp.de> I have made a new release of libev + libevent: Tarball is at: http://dist.schmorp.de/libev/ Documentation is linked from: http://software.schmorp.de/pkg/libev.html Changes: - the tarball now reflects both the libevent and libev version. - the patched libevent will install itself under the same names as libevent itself (but is not ABI compatible to it). - minimal mode has been further improved: rxvt-unicode 8.7 (with libev) is 10k smaller than rxvt-unicode 8.4 (with the older iom). - the priority semantics have been finalised (idle watcher semantics have changed considerably, but overall the system stayed the same as implemented). - the C++ callbacks have changed considerably: a callback now uses no additional memory in the watcher struct over a C callback, and can be as fast as a direct C callback. One can also use static emthods and plain functions as callbacks now, making the C++ watchers some fluffier inteface to libev. - the documentation has been extended with the priority changes and the C++ API change. - the libev core has seen considerable fine-tuning. while no new bugs have been found, a few might have been introduced, as usual... -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / pcg@goof.com -=====/_/_//_/\_,_/ /_/\_\ From eran at yedda.com Tue Dec 11 03:57:25 2007 From: eran at yedda.com (Eran Sandler) Date: Tue Dec 11 03:57:39 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 Message-ID: <475E50F5.6050209@yedda.com> Hello all, Does anyone knows the status of LibEvent 1.3e support in Windows? I grabbed the source of 1.3e and converted the old MSVC6 projects to VS2005 and had to fix a couple of things in the tests as well as in the library to make it compile. It does compile now, but none of the tests works as they should. Before I delve into the code itself and try to see whats the problem, do any of you know what's the status of the Windows code? Has anyone else tried to compile 1.3e on VS2005 (or any other MS compiler for that matter) ? The latest code that worked in Memcached-Win32 was a modified LibEvent 1.1. I'm trying to make this work to eventually have an up-to-date Win32 version of Memcached. Thanks in advance for any help, Eran Sandler From provos at citi.umich.edu Tue Dec 11 11:52:43 2007 From: provos at citi.umich.edu (Niels Provos) Date: Tue Dec 11 11:52:50 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <475E50F5.6050209@yedda.com> References: <475E50F5.6050209@yedda.com> Message-ID: <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> Hi Eran, Nick has been working on improving the Win32 code. I would suggest that you try 1.4.0-beta. Please, let me know if that works for you. Thanks, Niels. On Dec 11, 2007 12:57 AM, Eran Sandler wrote: > Hello all, > > Does anyone knows the status of LibEvent 1.3e support in Windows? > I grabbed the source of 1.3e and converted the old MSVC6 projects to > VS2005 and had to fix a couple of things in the tests as well as in the > library to make it compile. > > It does compile now, but none of the tests works as they should. > > Before I delve into the code itself and try to see whats the problem, do > any of you know what's the status of the Windows code? Has anyone else > tried to compile 1.3e on VS2005 (or any other MS compiler for that matter) ? > > The latest code that worked in Memcached-Win32 was a modified LibEvent 1.1. > I'm trying to make this work to eventually have an up-to-date Win32 > version of Memcached. > > Thanks in advance for any help, > Eran Sandler > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > > From eran at yedda.com Tue Dec 11 12:29:02 2007 From: eran at yedda.com (Eran Sandler) Date: Tue Dec 11 12:29:25 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> Message-ID: <475EC8DE.5080903@yedda.com> Hello Niels, I've spoken with Dormando, one of the memcached maintainers and they haven't test it with LibEvent 1.4.0. They do, however work with 1.3e on memcached 1.2.4 and the first tests of memcached 1.3.0. I would prefer to align memcached-win32 to work with whatever is being used in the main branch memcached (i.e. 1.3e). It would be great if we can back port some of this code to make 1.3e work well on Windows. Eran Niels Provos wrote: > Hi Eran, > > Nick has been working on improving the Win32 code. I would suggest > that you try 1.4.0-beta. > > Please, let me know if that works for you. > > Thanks, > Niels. > > On Dec 11, 2007 12:57 AM, Eran Sandler wrote: > >> Hello all, >> >> Does anyone knows the status of LibEvent 1.3e support in Windows? >> I grabbed the source of 1.3e and converted the old MSVC6 projects to >> VS2005 and had to fix a couple of things in the tests as well as in the >> library to make it compile. >> >> It does compile now, but none of the tests works as they should. >> >> Before I delve into the code itself and try to see whats the problem, do >> any of you know what's the status of the Windows code? Has anyone else >> tried to compile 1.3e on VS2005 (or any other MS compiler for that matter) ? >> >> The latest code that worked in Memcached-Win32 was a modified LibEvent 1.1. >> I'm trying to make this work to eventually have an up-to-date Win32 >> version of Memcached. >> >> Thanks in advance for any help, >> Eran Sandler >> _______________________________________________ >> Libevent-users mailing list >> Libevent-users@monkey.org >> http://monkeymail.org/mailman/listinfo/libevent-users >> >> >> From ilya at martynov.org Fri Dec 14 06:40:53 2007 From: ilya at martynov.org (Ilya Martynov) Date: Fri Dec 14 06:41:26 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp Message-ID: <47626BC5.2080705@martynov.org> Hi, I wonder if anybody could elaborate what is the reason for setting SO_LINGER option for sockets created by evhttp. I mean this part of code inside of http.c: static int bind_socket_ai(struct addrinfo *ai) { ... linger.l_onoff = 1; linger.l_linger = 5; setsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)&linger, sizeof(linger)); ... } If I'm reading the documentation correctly at least for Linux this makes close() on the socket to block what probably not a very good thing in programs based on libevent. From http://linux.about.com/od/commands/l/blcmdl7_socket.htm: SO_LINGER Sets or gets the SO_LINGER option. ... When enabled, a close(2) or shutdown(2) will not return until all queued messages for the socket have been successfully sent or the linger timeout has been reached. Otherwise, the call returns immediately and the closing is done in the background. -- Ilya Martynov, ilya@iponweb.net CTO IPonWEB (UK) Ltd From slamb at slamb.org Fri Dec 14 15:56:00 2007 From: slamb at slamb.org (Scott Lamb) Date: Fri Dec 14 15:56:07 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp In-Reply-To: <47626BC5.2080705@martynov.org> References: <47626BC5.2080705@martynov.org> Message-ID: <4762EDE0.30803@slamb.org> Ilya Martynov wrote: > Hi, > > I wonder if anybody could elaborate what is the reason for setting > SO_LINGER option for sockets created by evhttp. I mean this part of code > inside of http.c: > > static int > bind_socket_ai(struct addrinfo *ai) > { > ... > linger.l_onoff = 1; > linger.l_linger = 5; > setsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)&linger, > sizeof(linger)); > ... > } > > If I'm reading the documentation correctly at least for Linux this > makes close() on the socket to block what probably not a very good thing > in programs based on libevent. From > http://linux.about.com/od/commands/l/blcmdl7_socket.htm: > > SO_LINGER > Sets or gets the SO_LINGER option. ... When enabled, a close(2) or > shutdown(2) will not return until all queued messages for the socket > have been successfully sent or the linger timeout has been reached. > Otherwise, the call returns immediately and the closing is done in the > background. > I ran a bunch of tests on linger a while ago (by creating a socket pair and programmatically manipulating firewall rules to simulate packet loss). My results agree with your conclusion - this can cause the process to block for l_linger seconds on Linux. On OS X, this does *not* block if the socket is non-blocking - the behavior is not consistent between platforms. My conclusions were basically that the only use of SO_LINGER is to force an RST by passing {1, 0}. The default is {0, 0}. Tests and results here: http://www.slamb.org/svn/repos/trunk/projects/socket_tests/index.html I didn't test if linger options are inherited from the listen socket to accepted sockets, which this code seems to be assuming. From libev at schmorp.de Fri Dec 14 16:18:03 2007 From: libev at schmorp.de (Marc Lehmann) Date: Fri Dec 14 16:18:30 2007 Subject: [Libevent-users] libev-1.85 release Message-ID: <20071214211803.GA22557@schmorp.de> Libev 1.85 has just been released (together with the corresponding perl module). Distribution: http://dist.schmorp.de/libev/ Documenttaion: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod The biggest change is that libev now comes in two tarballs: one libevent+libev tarball containing a patched libevent, and one with the standalone libev version. Other major changes (since 1.7) include: - the epoll backend uses some heuristics that avoid superfluous EPOLL_CTL_DEL calls, which can majorly speed up common usage patterns (the same technique could be applied to the kqueue backend). stopping and starting a watcher is now very cheap and will not result in additional syscalls. - a bug in the heap management functions has been fixed that could rarely cause timers to be delayed. - the long term numeric stability of periodic watchers has been improved, as well as timing accuracy in general. - ev_signal_start wasn't in fact async-signal safe and will now block all signals during installation of the watcher. - the API version has been set to 1:0 and will be maintained from now on. - the C++ callback API has changed considerably, and will now be zero-overhead w.r.t. to watcher size, and can be zero-overhead when the compiler is able to inline the method callback into the C thunking code (use gcc :). I do expect some packaging problems, as this is the first tarball release ever. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / pcg@goof.com -=====/_/_//_/\_,_/ /_/\_\ From libev at schmorp.de Fri Dec 14 19:14:25 2007 From: libev at schmorp.de (Marc Lehmann) Date: Fri Dec 14 19:14:30 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp In-Reply-To: <4762EDE0.30803@slamb.org> References: <47626BC5.2080705@martynov.org> <4762EDE0.30803@slamb.org> Message-ID: <20071215001425.GA22975@schmorp.de> On Fri, Dec 14, 2007 at 12:56:00PM -0800, Scott Lamb wrote: > Tests and results here: > > http://www.slamb.org/svn/repos/trunk/projects/socket_tests/index.html "The UNIX socket API has been standardized for a decade. But the standards are vague on a lot of critical behavior." In defendence of the standards (in this case the single unix spec.), the blocking behaviour is _mandated_ by the SUS, and not following this behaviour is a bug if the platform claims to follow unix behaviour. Of course, OS X is quite far from any unix behaviour, so the portability problem remains. The problems are, however, far fewer in number if one only tests unix platforms, which also have problematic behaviours but overall perform much better than the unix emulation in os x. However, that page has a lot of problems, for example it requires non-standard behaviour and declares standard behaviour as "failure", an example would be: read(0) while connecting EWOULDBLOCK failure (linux) 0 failure (os x) EWOULDBLOCK is not a standard error code, the standard only documents EAGAIN (which is what linux actually returns). The test expects EINPROGRESS, but that is not allowed by the unix standard, so a platform actually getting a green status there would be _broken_. Also, returning 0 is also allowed in this case, so the os x test is also errornously marked as failing, when, in fact, it is fully standards compliant. So while the raw results of that page are very interesting, it would be more useful if the interpretation as failure or not would not _require_ behaviour that is wrong by de-facto and actual standards. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / pcg@goof.com -=====/_/_//_/\_,_/ /_/\_\ From provos at citi.umich.edu Fri Dec 14 20:42:51 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri Dec 14 20:43:05 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp In-Reply-To: <47626BC5.2080705@martynov.org> References: <47626BC5.2080705@martynov.org> Message-ID: <850f7cbe0712141742y645750f8ya1ec0b82685200b6@mail.gmail.com> Hi Ilya, thanks for the report. It seems that the SO_LINGER is not necessary there. I put this into the tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1851137&group_id=50884&atid=461322 You can see updates there. Thank you, Niels. On Dec 14, 2007 3:40 AM, Ilya Martynov wrote: > Hi, > > I wonder if anybody could elaborate what is the reason for setting > SO_LINGER option for sockets created by evhttp. I mean this part of code > inside of http.c: > > static int > bind_socket_ai(struct addrinfo *ai) > { > ... > linger.l_onoff = 1; > linger.l_linger = 5; > setsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)&linger, > sizeof(linger)); > ... > } > > If I'm reading the documentation correctly at least for Linux this > makes close() on the socket to block what probably not a very good thing > in programs based on libevent. From > http://linux.about.com/od/commands/l/blcmdl7_socket.htm: > > SO_LINGER > Sets or gets the SO_LINGER option. ... When enabled, a close(2) or > shutdown(2) will not return until all queued messages for the socket > have been successfully sent or the linger timeout has been reached. > Otherwise, the call returns immediately and the closing is done in the > background. > > -- > Ilya Martynov, ilya@iponweb.net > CTO IPonWEB (UK) Ltd > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > > From slamb at slamb.org Fri Dec 14 20:47:24 2007 From: slamb at slamb.org (Scott Lamb) Date: Fri Dec 14 20:47:27 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp In-Reply-To: <20071215001425.GA22975@schmorp.de> References: <47626BC5.2080705@martynov.org> <4762EDE0.30803@slamb.org> <20071215001425.GA22975@schmorp.de> Message-ID: <4763322C.1010203@slamb.org> Marc Lehmann wrote: > On Fri, Dec 14, 2007 at 12:56:00PM -0800, Scott Lamb wrote: >> Tests and results here: >> >> http://www.slamb.org/svn/repos/trunk/projects/socket_tests/index.html > > "The UNIX socket API has been standardized for a decade. But the standards > are vague on a lot of critical behavior." > > In defendence of the standards (in this case the single unix spec.), > the blocking behaviour is _mandated_ by the SUS, and not following this > behaviour is a bug if the platform claims to follow unix behaviour. Of > course, OS X is quite far from any unix behaviour, so the portability > problem remains. > > The problems are, however, far fewer in number if one only tests unix > platforms, which also have problematic behaviours but overall perform much > better than the unix emulation in os x. I'm not going to get into stupid hairsplitting about what "unix emulation" vs "unix platforms" means, but OS X's networking code was largely inherited from FreeBSD. I would expect older FreeBSD systems to have the same behavior. > However, that page has a lot of problems, for example it requires > non-standard behaviour and declares standard behaviour as "failure", an > example would be: > > read(0) while connecting > > EWOULDBLOCK failure (linux) > 0 failure (os x) > > EWOULDBLOCK is not a standard error code, the standard only documents EAGAIN > (which is what linux actually returns). The test expects EINPROGRESS, but > that is not allowed by the unix standard, so a platform actually getting a > green status there would be _broken_. EWOULDBLOCK is how the Python library reported the error. On Linux, EWOULDBLOCK and EAGAIN are synonymous. > > Also, returning 0 is also allowed in this case, so the os x test is also > errornously marked as failing, when, in fact, it is fully standards > compliant. > > So while the raw results of that page are very interesting, it would be > more useful if the interpretation as failure or not would not _require_ > behaviour that is wrong by de-facto and actual standards. > I chose "failure" vs. "success" criteria rather arbitrarily - especially in the cases where I couldn't find a clear answer in the standard, they were basically just "was it the same as the first platform I tried that test on". I should probably remove the color coding. If you take a more thorough look at the page, you'll see a note to that effect. From nickm at freehaven.net Sun Dec 16 15:30:25 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Sun Dec 16 15:30:43 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <475EC8DE.5080903@yedda.com> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> <475EC8DE.5080903@yedda.com> Message-ID: <20071216203025.GA13098@catbus.wangafu.net> On Tue, Dec 11, 2007 at 07:29:02PM +0200, Eran Sandler wrote: > Hello Niels, > > I've spoken with Dormando, one of the memcached maintainers and they > haven't test it with LibEvent 1.4.0. They do, however work with 1.3e on > memcached 1.2.4 and the first tests of memcached 1.3.0. I hope they get a chance to try it soon; the next 1.4.x beta release will probably be the last beta before we have a 1.4 production release. :) > I would prefer to align memcached-win32 to work with whatever is being > used in the main branch memcached (i.e. 1.3e). > It would be great if we can back port some of this code to make 1.3e > work well on Windows. I've checked in some changes to the 1.3 libevent branch that should make the next libevent 1.3 release work better on MSVC. It will still be kind of wonkier than 1.4.x, for the following reasons: - I don't have a copy of MSVC6 any more; the changes in question are only tested on MSVC 2005 Express. If somebody sends me a corrected project file for MSVC6, I'll check it in. - In 1.4.x and later, libevent ships with a separate header file, "event-config.h", that's automatically generated from autoconf's output and post-processed so that the macros don't conflict. The upshot of this is that with newer versions of libevent, you shouldn't need to define any extra types or include any extra headers before you #include "event.h". This is not true of older versions. You can see the latest 1.3 code by using a subversion client (like TortoiseSVN) to check out https://levent.svn.sourceforge.net/svnroot/levent/branches/patches-1.3 Yrs, -- Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071216/51229687/attachment.bin From eran at yedda.com Mon Dec 17 01:40:28 2007 From: eran at yedda.com (Eran Sandler) Date: Mon Dec 17 01:40:43 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <20071216203025.GA13098@catbus.wangafu.net> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> <475EC8DE.5080903@yedda.com> <20071216203025.GA13098@catbus.wangafu.net> Message-ID: <476619DC.9000803@yedda.com> Nick Mathewson wrote: > I hope they get a chance to try it soon; the next 1.4.x beta release > will probably be the last beta before we have a 1.4 production > release. :) > I'll talk with Dormando about starting a branch that users 1.4, even if its just for having an integrated Win32 version of memcached. > > I've checked in some changes to the 1.3 libevent branch that should > make the next libevent 1.3 release work better on MSVC. It will still > be kind of wonkier than 1.4.x, for the following reasons: > > - I don't have a copy of MSVC6 any more; the changes in question are > only tested on MSVC 2005 Express. If somebody sends me a corrected > project file for MSVC6, I'll check it in. > Any chance you can simply check in your VS2005 project files. I think its about time we can start using VS2005 and leave MSVC (unless there is anything specific in VS2005 that is preventing us from doing so). Thanks for checking some of the stuff to the 1.3 branch. I'll get your changes and see if I can make the tests work again, in which case I'll be able to start patching up the older Win32 memcached code to 1.2.4. -- Eran From mcvsubbu at yahoo.com Tue Dec 18 20:17:38 2007 From: mcvsubbu at yahoo.com (Subbu Subramaniam) Date: Tue Dec 18 20:24:28 2007 Subject: [Libevent-users] Signals question regarding libevent Message-ID: <125704.41533.qm@web32508.mail.mud.yahoo.com> Hi, What is the right way to handle siganls while using libevent? Am I supposed to use signal_set()/signal_add() etc. calls, or am I supposed to install my own signal handler and use event_sigcb and event_gotsig (or, am I supposed to do both somehow?) Thanks -Subbu -- Subbu Subramaniam From provos at citi.umich.edu Tue Dec 18 20:42:02 2007 From: provos at citi.umich.edu (Niels Provos) Date: Tue Dec 18 20:42:04 2007 Subject: [Libevent-users] Signals question regarding libevent In-Reply-To: <125704.41533.qm@web32508.mail.mud.yahoo.com> References: <125704.41533.qm@web32508.mail.mud.yahoo.com> Message-ID: <850f7cbe0712181742x129e96a3o7cc2c999a5428070@mail.gmail.com> Hi Subbu, please, use signal_{set,add,del} for handling signals when you use libevent. Niels. On Dec 18, 2007 5:17 PM, Subbu Subramaniam wrote: > Hi, > > What is the right way to handle siganls while using libevent? > > Am I supposed to use signal_set()/signal_add() etc. calls, or am I supposed to > install my own signal handler and use event_sigcb and event_gotsig (or, am I > supposed to do both somehow?) > > Thanks > > -Subbu > > -- > Subbu Subramaniam > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users > > From provos at citi.umich.edu Wed Dec 19 01:35:01 2007 From: provos at citi.umich.edu (Niels Provos) Date: Wed Dec 19 01:35:33 2007 Subject: [Libevent-users] SO_LINGER option for sockets created by evhttp In-Reply-To: <850f7cbe0712141742y645750f8ya1ec0b82685200b6@mail.gmail.com> References: <47626BC5.2080705@martynov.org> <850f7cbe0712141742y645750f8ya1ec0b82685200b6@mail.gmail.com> Message-ID: <850f7cbe0712182235x120c8cd6j68f7001288acd942@mail.gmail.com> This has been fixed in trunk and the 1.4 branch. Thanks, Niels. On Dec 14, 2007 5:42 PM, Niels Provos wrote: > Hi Ilya, > > thanks for the report. It seems that the SO_LINGER is not necessary > there. I put this into the tracker: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1851137&group_id=50884&atid=461322 > > You can see updates there. > > Thank you, > Niels. > > > On Dec 14, 2007 3:40 AM, Ilya Martynov wrote: > > Hi, > > > > I wonder if anybody could elaborate what is the reason for setting > > SO_LINGER option for sockets created by evhttp. I mean this part of code > > inside of http.c: > > > > static int > > bind_socket_ai(struct addrinfo *ai) > > { > > ... > > linger.l_onoff = 1; > > linger.l_linger = 5; > > setsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)&linger, > > sizeof(linger)); > > ... > > } > > > > If I'm reading the documentation correctly at least for Linux this > > makes close() on the socket to block what probably not a very good thing > > in programs based on libevent. From > > http://linux.about.com/od/commands/l/blcmdl7_socket.htm: > > > > SO_LINGER > > Sets or gets the SO_LINGER option. ... When enabled, a close(2) or > > shutdown(2) will not return until all queued messages for the socket > > have been successfully sent or the linger timeout has been reached. > > Otherwise, the call returns immediately and the closing is done in the > > background. > > > > -- > > Ilya Martynov, ilya@iponweb.net > > CTO IPonWEB (UK) Ltd > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkeymail.org/mailman/listinfo/libevent-users > > > > > From mcvsubbu at yahoo.com Wed Dec 19 12:11:36 2007 From: mcvsubbu at yahoo.com (Subbu Subramaniam) Date: Wed Dec 19 12:11:39 2007 Subject: [Libevent-users] Signals question regarding libevent In-Reply-To: <850f7cbe0712181742x129e96a3o7cc2c999a5428070@mail.gmail.com> Message-ID: <758762.72596.qm@web32511.mail.mud.yahoo.com> A follow-up question. Can the same signal be registered multiple times, each with a different void * context? Is the expectation that the callback will be called multiple times correct? In the attached program, the callback function seems to be called only once, even though it is registered two times. I tried it in FreeBSD-4.11/libevent-1.1b, and RHEL-2.6.9/libevent-1.3e. In Freebsd, the last registered void * is given in the callback whereas in linux, it is the first one. But the callback happens only once. Is this a bug? -Subbu --- Niels Provos wrote: > Hi Subbu, > > please, use signal_{set,add,del} for handling signals when you use libevent. > > Niels. > > On Dec 18, 2007 5:17 PM, Subbu Subramaniam wrote: > > Hi, > > > > What is the right way to handle siganls while using libevent? > > > > Am I supposed to use signal_set()/signal_add() etc. calls, or am I supposed > to > > install my own signal handler and use event_sigcb and event_gotsig (or, am > I > > supposed to do both somehow?) > > > > Thanks > > > > -Subbu > > > > -- > > Subbu Subramaniam > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkeymail.org/mailman/listinfo/libevent-users > > > > > -- Subbu Subramaniam -------------- next part -------------- A non-text attachment was scrubbed... Name: sigtest2.c Type: application/octet-stream Size: 2020 bytes Desc: 2062010864-sigtest2.c Url : http://monkeymail.org/archives/libevent-users/attachments/20071219/12459cd7/sigtest2.obj From nickm at freehaven.net Mon Dec 24 23:57:20 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Dec 24 23:57:28 2007 Subject: [Libevent-users] ANN: Libevent 1.4.1-beta released Message-ID: <20071225045720.GR13545@catbus.wangafu.net> Hello, everyone! Once again, it's time for a beta release on the Libevent 1.4.x series. This time, it's 1.4.1-beta. You can get the source here: http://www.monkey.org/~provos/libevent-1.4.1-beta.tar.gz If you maintain a project that uses libevent, please try 1.4.1-beta as soon as you can, so that if you find any bugs, we can fix them before the official release. There are some new features, some improved features, and a lot of bug fixes since 1.4.0-beta. Here's a summary of what's changed since the last beta in this series: - New APIs - There's a new event_base_new() function that acts as event_init(), but does not replace the default base. - There's an event_reinit() to reinitialize an event_base after a fork has called. - Add a 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. - RPC structures can now use 32-bit numbers as tags; this is wire-compatible, but changes the APIs slightly. - Performance - The windows select loop is now O(n lg n) in performance rather than O(n^2). It's not as good as being fully IOCP, but that will have to wait for the next development series. - Bugfixes - Fix some memory leaks; make event_base_free() work more correctly. - Signal handling with kqueue is now more more consistent with other backends. - And many more! See the Changelog for full details. This is only what's new since the last beta, 1.4.0-beta. The 1.4.x series as a whole has lots of new features since the 1.3 series. Niels and I are writing a "What's New In Libevent 1.4" document to explain the main differences; I'll send a copy to the list once it's more done. You can see the latest draft at https://levent.svn.sourceforge.net/svnroot/levent/branches/patches-1.4/libevent/whatsnew-14.txt There is also more development going on in the trunk, outside of the 1.4.x branch. I don't know whether this will turn into 1.5 or 2.0 when it's done, but it will probably include substantial performance improvements, faster Win32 support, major API cleanups, and the like. 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 Peace on earth, and good will to everyone! yrs, -- Nick Mathewson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071224/e45e3644/attachment-0001.bin From nickm at freehaven.net Thu Dec 27 19:35:32 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Thu Dec 27 19:35:44 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <476619DC.9000803@yedda.com> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> <475EC8DE.5080903@yedda.com> <20071216203025.GA13098@catbus.wangafu.net> <476619DC.9000803@yedda.com> Message-ID: <20071228003532.GN5580@catbus.wangafu.net> On Mon, Dec 17, 2007 at 08:40:28AM +0200, Eran Sandler wrote: [...] > Any chance you can simply check in your VS2005 project files. I think > its about time we can start using VS2005 and leave MSVC (unless there is > anything specific in VS2005 that is preventing us from doing so). It should all be checked in to the subversion repository. I added a .sln file and a .vcproj file; is there anything else? As noted, I'm not much of a windows person, so it's likely there are mistakes; please let me know what they are. :) yrs, -- Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071227/43e2a4de/attachment.bin From wenewboy at gmail.com Fri Dec 28 06:16:45 2007 From: wenewboy at gmail.com (wenew zhang) Date: Fri Dec 28 06:17:01 2007 Subject: [Libevent-users] hi, i install libevent1.3 and 1.4beta on freebsd7 beta, and it cant' run the test normal Message-ID: <4eaa09eb0712280316h27ad5720s14c803c87c0d947c@mail.gmail.com> when i try to run test.sh, it's skip all include kqueue, and then: make clean, make i got a message:regress.c1242 error:'from_name' undeclared(first use in this function) ...... i get the same message in libevent1.41 and 1.3e best regards wenew zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071228/e8169f5a/attachment.htm From slamb at slamb.org Sat Dec 29 04:50:02 2007 From: slamb at slamb.org (Scott Lamb) Date: Sat Dec 29 04:49:56 2007 Subject: [Libevent-users] [PATCH] benchmark chart generator Message-ID: <4776184A.9050708@slamb.org> I was frustrated with the gap between bench.c and decent charts, so I made the attached patch. It adds a simple Python program to generate these with gnuplot. I've also attached sample output (one-active.png). Best regards, Scott -- Scott Lamb -------------- next part -------------- A non-text attachment was scrubbed... Name: one-active.png Type: image/png Size: 6173 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071229/02ea1296/one-active.png -------------- next part -------------- Add a chart generator. Also clean up what appears to be a totally extraneous error output from bench.c. Index: test/chartbench.py =================================================================== --- test/chartbench.py (revision 0) +++ test/chartbench.py (revision 0) @@ -0,0 +1,181 @@ +#!/usr/bin/env python +""" +%prog [options] + +Creates libevent benchmark charts. + +Requirements: +* Python >= 2.4 for the subprocess module +* test-init and bench in current directory +* gnuplot with png output format (and optionally freetype support) +""" + +from __future__ import division + +import optparse +import os +import subprocess +import sys +import traceback + +ALL_METHODS = 'kqueue devpoll poll select epoll evport'.split(' ') + +STYLE_MAP = { + 'candlesticks': 'using 1:3:2:6:5 with candlesticks linewidth 2', + 'lines': 'using 1:4 with lines linewidth 2 smooth csplines', +} + +def get_environment(method): + """Returns an environment that makes libevent use the specified method.""" + env = {} + for i in ALL_METHODS: + if i != method: + env['EVENT_NO%s' % i.upper()] = 'yes' + return env + +def median(data): + """Returns the median of a sorted list of numbers.""" + n = len(data) + if n % 2 == 0: + return (data[n//2] + data[n//2+1]) / 2 + else: + return data[n//2] + +def run_bench(method, pipes, active, writes): + """Gets candestick bounds for a given test. + + Returns (minimum, first quartile, median, third quartile, maximum). + """ + print 'run_bench(%r, %d, %d, %d)' % (method, pipes, active, writes) + + # Get the data. + bench = subprocess.Popen(('./bench -n %d -a %d -w %d' + % (pipes, active, writes)).split(' '), + bufsize=1, stdout=subprocess.PIPE, + env=get_environment(method)) + data = [float(line) for line in bench.stdout] + retval = bench.wait() + if retval != 0: + raise Exception('bench returned %d' % retval) + if not data: + raise Exception('bench returned insufficient data') + + # Now get our statistics. + data.sort() + return (data[0], + median(data[0:len(data)//2]), + median(data), + median(data[len(data)//2:]), + data[-1]) + +def escape(literal): + """Escapes the given literal for use in gnuplot control channel. + + See gnuplot's "help syntax" for details.""" + return ('"%s"' % literal.replace('\\', '\\\\') + .replace('"', '\\"') + .replace('\n', '\\n')) + +def plot(filename, title, options, methods, active, writes): + """Creates the plot described by the arguments.""" + + # Launch gnuplot. It wants to poke around at my environment, so I won't + # give it one. (At least if it gets an unusable $DISPLAY, it's unhappy.) + if options.store_commands: + gnuplot_out = open('%s.plot' % filename, 'w') + else: + gnuplot = subprocess.Popen(['gnuplot'], stdin=subprocess.PIPE, + env={'PATH': os.environ['PATH']}) + gnuplot_out = gnuplot.stdin + + if options.font is None: + gnuplot_out.write('set terminal png\n') + else: + gnuplot_out.write('set terminal png font %s %d\n' + % (escape(options.font), options.fontsize)) + gnuplot_out.write(""" + set output %(filename)s + set title %(title)s + set xlabel "Inactive file descriptors" + set ylabel "Time (\xC2\xB5s)" + set palette color + set style fill solid + set key top left + set logscale y 10 + set style line 1 lc rgb "#888888" + set border 3 linestyle 1 + set xtics out nomirror textcolor rgb "#000000" + set ytics out nomirror textcolor rgb "#000000" + set grid + """ % { + 'title': escape(title), + 'filename': escape(filename), + }) + gnuplot_out.write('plot [0:] [] ' + + ', '.join(['"-" %s title %s' + % (STYLE_MAP[options.style], escape(method)) + for method in methods]) + + '\n') + + # Write data for each method. + for method in methods: + for i in range(0, options.max+options.step, options.step): + stats = run_bench(method=method, + pipes=i+active, + active=active, + writes=writes) + gnuplot_out.write('%d %g %g %g %g %g\n' % tuple((i,) + stats)) + gnuplot_out.write('e\n') + + # Finish up. + if not options.store_commands: + gnuplot_out.close() + retval = gnuplot.wait() + if retval != 0: + raise Exception('gnuplot failure') + +def main(args): + # Parse arguments. + parser = optparse.OptionParser(usage=__doc__) + parser.add_option('-s', '--step', dest='step', default=250, type='int', + help='plot a point every STEP file descriptors') + parser.add_option('-m', '--max', dest='max', default=25000, type='int', + help='maximum number of file descriptors') + parser.add_option('--style', dest='style', default='candlesticks', + help='plot style', choices=STYLE_MAP.keys()) + parser.add_option('--font', dest='font', + help='path to TTF file (requires gnuplot support)') + parser.add_option('--font-size', dest='fontsize', default=10, type='int', + help='in points; only used if FONT is specified') + parser.add_option('--store-commands', dest='store_commands', default=False, + help='store commands rather than executing gnuplot', + action='store_true') + options, args = parser.parse_args() + if len(args) != 0: + parser.error('No positional arguments expected') + + # Determine what methods are supported. + supported_methods = [] + for method in ALL_METHODS: + if subprocess.call('./test-init', env=get_environment(method)) == 0: + supported_methods.append(method) + if not supported_methods: + raise Exception('No supported methods') + print 'supported methods: %s' % ' '.join(supported_methods) + + # Plot. + plot(filename='one-active.png', + title='1 active connection and 1 write', + options=options, + methods=supported_methods, + active=1, + writes=1) + plot(filename='many-active.png', + title='100 active connections and 1000 writes', + options=options, + methods=supported_methods, + active=100, + writes=1000) + +if __name__ == '__main__': + sys.exit(main(sys.argv)) Property changes on: test/chartbench.py ___________________________________________________________________ Name: svn:executable + * Name: svn:mime-type + text/plain Name: svn:eol-style + native Index: test/bench.c =================================================================== --- test/bench.c (revision 621) +++ test/bench.c (working copy) @@ -102,17 +102,12 @@ count = 0; writes = num_writes; - { int xcount = 0; gettimeofday(&ts, NULL); do { event_loop(EVLOOP_ONCE | EVLOOP_NONBLOCK); - xcount++; } while (count != fired); gettimeofday(&te, NULL); - if (xcount != count) fprintf(stderr, "Xcount: %d, Rcount: %d\n", xcount, count); - } - evutil_timersub(&te, &ts, &te); return (&te); From eran at yedda.com Sun Dec 30 09:37:49 2007 From: eran at yedda.com (Eran Sandler) Date: Sun Dec 30 09:38:05 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <20071228003532.GN5580@catbus.wangafu.net> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> <475EC8DE.5080903@yedda.com> <20071216203025.GA13098@catbus.wangafu.net> <476619DC.9000803@yedda.com> <20071228003532.GN5580@catbus.wangafu.net> Message-ID: <4777AD3D.8070105@yedda.com> Nick Mathewson wrote: > > It should all be checked in to the subversion repository. I added a > .sln file and a .vcproj file; is there anything else? > > As noted, I'm not much of a windows person, so it's likely there are > mistakes; please let me know what they are. :) > Thanks Nick. I hope to get around to checking it soon. There are some differences from the modified libevent code that was used in the win32 version of memcached and the current libevent 1.4 code and I'm not sure which is better (yet). Eran From nickm at freehaven.net Sun Dec 30 17:06:10 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Sun Dec 30 17:06:19 2007 Subject: [Libevent-users] LibEvent 1.3e - Compiling for Windows using VS2005 In-Reply-To: <4777AD3D.8070105@yedda.com> References: <475E50F5.6050209@yedda.com> <850f7cbe0712110852u7d155ed1keeb9462de935b94@mail.gmail.com> <475EC8DE.5080903@yedda.com> <20071216203025.GA13098@catbus.wangafu.net> <476619DC.9000803@yedda.com> <20071228003532.GN5580@catbus.wangafu.net> <4777AD3D.8070105@yedda.com> Message-ID: <20071230220610.GF8750@catbus.wangafu.net> On Sun, Dec 30, 2007 at 04:37:49PM +0200, Eran Sandler wrote: > Nick Mathewson wrote: > > > >It should all be checked in to the subversion repository. I added a > >.sln file and a .vcproj file; is there anything else? > > > >As noted, I'm not much of a windows person, so it's likely there are > >mistakes; please let me know what they are. :) > > > > Thanks Nick. I hope to get around to checking it soon. > There are some differences from the modified libevent code that was used > in the win32 version of memcached and the current libevent 1.4 code and > I'm not sure which is better (yet). If there are fixes in the modified code, could you please send me a pointer to code, and let me know which version of libevent it's based on? I'd like to check for any fixes we missed so we can merge them into the primary codebase. yrs, -- Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071230/08f529b0/attachment-0001.bin From nickm at freehaven.net Mon Dec 31 15:46:29 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Dec 31 15:46:41 2007 Subject: [Libevent-users] hi, i install libevent1.3 and 1.4beta on freebsd7 beta, and it cant' run the test normal In-Reply-To: <4eaa09eb0712280316h27ad5720s14c803c87c0d947c@mail.gmail.com> References: <4eaa09eb0712280316h27ad5720s14c803c87c0d947c@mail.gmail.com> Message-ID: <20071231204629.GF29624@catbus.wangafu.net> On Fri, Dec 28, 2007 at 07:16:45PM +0800, wenew zhang wrote: > when i try to run test.sh, > it's skip all include kqueue, > and then: > make clean, > make > i got a message:regress.c1242 error:'from_name' undeclared(first use in this > function) > ...... > > i get the same message in libevent1.41 and 1.3e > It looks like maybe the regress.gen.c and regress.gen.h files are generated with an old version of the RPC python script; the new definition of EVTAG_ASSIGN should not give that error. Is anybody else seeing this message? I'm trying to reproduce it, but I haven't found any way to do so. yrs, -- Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071231/124f3fa8/attachment.bin