From wouter at NLnetLabs.nl Mon Oct 1 08:11:36 2007 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Mon Oct 1 08:12:07 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <20070927225351.GB18876@ns1.anodized.com> References: <20070927055041.GA18876@ns1.anodized.com> <850f7cbe0709270831r4153318o6336aeced7e16e6@mail.gmail.com> <20070927225351.GB18876@ns1.anodized.com> Message-ID: <4700E3F8.90107@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'll speak up again, and say that I think the features do not belong in the library. It is feature bloat - for libevent - but perhaps not in their own library, where they would be enriched features built upon libevent. My argument was not based on 30Kb library, but on lines of code, and thus also code complexity and bugs, that it has. More code means more maintenance, luckily Nick is helping you now. Best regards, Wouter Christopher Layne wrote: > On Thu, Sep 27, 2007 at 08:31:32AM -0700, Niels Provos wrote: >> Hi Christopher, >> >> I am not sure if this is necessarily the right way to go for a >> library, esp if it can impact backwards compatibility for >> bufferevents. As for reducing the size of the library, do you really >> think that 30K make a difference these days? >> >> Niels. > > It won't impact backwards compatibility unless someone explictly removed > support for bufferevents. Additionally, where do we draw the line on > what makes a difference these days, when it comes down to it? 1M? 2M? > On a typical *bsd/linux platform, I agree, it won't make a significant > difference at the end of the day. I also agree that using autoconf and > automake to manipulate things is a hack in itself (they always feel like > a hack unfortunately). I also don't know how many people are using > libevent on smaller platforms (embedded, etc) but I thought that perhaps > it could have had some kind of benefit. > > Part of my impetus was based on this post which directly identifies some > concerns and ideas: > > -- >>From provos@citi.umich.edu Thu Feb 8 11:31:50 2007 > From: provos@citi.umich.edu (Niels Provos) > Date: Thu Feb 8 11:31:53 2007 > Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS > servers to evdns.c (This time with regression tests!) > In-Reply-To: <45BF380D.9030307@nlnetlabs.nl> > References: <20070129180804.GY22997@totoro.wangafu.net> > <45BF380D.9030307@nlnetlabs.nl> > Message-ID: <850f7cbe0702080831v158ffa5of3e54456c5330a75@mail.gmail.com> > Status: RO > Content-Length: 720 > Lines: 16 > > On 1/30/07, Wouter Wijngaards wrote: >> Please, why put these really big http and dns protocols into an event >> handling library? I would prefer libevent to stay focused on providing >> portable select() and alternatives wrappers. >> >> The http and evdns are pretty big compared to the rest of libevent. They >> can be put in their own library(or -ies) perhaps? Some sort of >> libevent-driven application support? > > There has been some talk about libevent creating two different > libraries during compile. One would be the traditional libevent and > the other one would layer on top of it. Still thinking about the > best way of doing this, but you are not the only one with concerns > about bloat. > > Niels. > -- > > So based on that, I went and wrote a patch. > > -cl > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHAOP4kDLqNwOhpPgRAts5AKCNRbr//JnAqLV2OMmhtp1SPy2HjQCfdrVL 85SGZbpBvUMo3OhKpvaUjyU= =603c -----END PGP SIGNATURE----- From lewislp at yahoo.com Mon Oct 1 18:46:42 2007 From: lewislp at yahoo.com (Larry Lewis) Date: Mon Oct 1 18:53:34 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents Message-ID: <545642.10681.qm@web51901.mail.re2.yahoo.com> +1 for the features not belonging in the library. I'd recommend moving those features out into supporting libraries (libevent-http/libevent-dns?) or even just using them as samples. Most users would probably end up tweaking the http code anyways, in my opinion. Otherwise, I'm using libevent as the basis for a set of single-threaded C++ class libraries (sockets and timers and such), and so far, I'm extremely happy with it. Thanks for great library. Larry ----- Original Message ---- From: Wouter Wijngaards To: Christopher Layne Cc: libevent-users@monkey.org Sent: Monday, October 1, 2007 8:11:36 AM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'll speak up again, and say that I think the features do not belong in the library. It is feature bloat - for libevent - but perhaps not in their own library, where they would be enriched features built upon libevent. My argument was not based on 30Kb library, but on lines of code, and thus also code complexity and bugs, that it has. More code means more maintenance, luckily Nick is helping you now. Best regards, Wouter Christopher Layne wrote: > On Thu, Sep 27, 2007 at 08:31:32AM -0700, Niels Provos wrote: >> Hi Christopher, >> >> I am not sure if this is necessarily the right way to go for a >> library, esp if it can impact backwards compatibility for >> bufferevents. As for reducing the size of the library, do you really >> think that 30K make a difference these days? >> >> Niels. > > It won't impact backwards compatibility unless someone explictly removed > support for bufferevents. Additionally, where do we draw the line on > what makes a difference these days, when it comes down to it? 1M? 2M? > On a typical *bsd/linux platform, I agree, it won't make a significant > difference at the end of the day. I also agree that using autoconf and > automake to manipulate things is a hack in itself (they always feel like > a hack unfortunately). I also don't know how many people are using > libevent on smaller platforms (embedded, etc) but I thought that perhaps > it could have had some kind of benefit. > > Part of my impetus was based on this post which directly identifies some > concerns and ideas: > > -- >>From provos@citi.umich.edu Thu Feb 8 11:31:50 2007 > From: provos@citi.umich.edu (Niels Provos) > Date: Thu Feb 8 11:31:53 2007 > Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS > servers to evdns.c (This time with regression tests!) > In-Reply-To: <45BF380D.9030307@nlnetlabs.nl> > References: <20070129180804.GY22997@totoro.wangafu.net> > <45BF380D.9030307@nlnetlabs.nl> > Message-ID: <850f7cbe0702080831v158ffa5of3e54456c5330a75@mail.gmail.com> > Status: RO > Content-Length: 720 > Lines: 16 > > On 1/30/07, Wouter Wijngaards wrote: >> Please, why put these really big http and dns protocols into an event >> handling library? I would prefer libevent to stay focused on providing >> portable select() and alternatives wrappers. >> >> The http and evdns are pretty big compared to the rest of libevent. They >> can be put in their own library(or -ies) perhaps? Some sort of >> libevent-driven application support? > > There has been some talk about libevent creating two different > libraries during compile. One would be the traditional libevent and > the other one would layer on top of it. Still thinking about the > best way of doing this, but you are not the only one with concerns > about bloat. > > Niels. > -- > > So based on that, I went and wrote a patch. > > -cl > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHAOP4kDLqNwOhpPgRAts5AKCNRbr//JnAqLV2OMmhtp1SPy2HjQCfdrVL 85SGZbpBvUMo3OhKpvaUjyU= =603c -----END PGP SIGNATURE----- _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071001/030da7dc/attachment.htm From nickm at freehaven.net Mon Oct 1 19:20:04 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Oct 1 19:20:21 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <545642.10681.qm@web51901.mail.re2.yahoo.com> References: <545642.10681.qm@web51901.mail.re2.yahoo.com> Message-ID: <20071001232004.GC3927@totoro.wangafu.net> On Mon, Oct 01, 2007 at 03:46:42PM -0700, Larry Lewis wrote: > +1 for the features not belonging in the library. I'd recommend > moving those features out into supporting libraries > (libevent-http/libevent-dns?) or even just using them as samples. > Most users would probably end up tweaking the http code anyways, in > my opinion. Here's an updated excerpt from the mail I sent Niels back in February, the last time people were talking about this: Niels wrote: > BTW, do you have an opinion about putting the more heavy-weight > libevent stuff into a separate library? Personally, I don't feel very strongly about this, but I'd vote for two libraries built from a single source package, or for two libraries. My reasoning against having only one library is this: I'd like to see the core of libevent get used by more projects, but the larger it becomes, the more work is required to maintain it, and port it to new platforms. I'd like to see the libevent core usable as a back-end by other general-purpose network utility libraries, like apr and glib and Twisted. These libraries already have their own implementations for things like http and rpc, though, and really don't need the ones in libevent. [...] My reason for preferring a single source package is that I'd like the I'd like the extended stuff to be available by default everywhere libevent is available, which is easiest if you have package maintainers start shipping two libraries from one package. (If you create a new source package, that will take more time to see any adoption.) [...] Of course, if you'd rather keep it as one package, I don't think my reasons above are really compelling. Factoring libraries is kind of a bike-shed problem; it's easy to form an opinion, and hard to show that any opinion is significantly better than any other. So, I don't really agree with the original patch either. As a maintainer for an application that uses libevent, it's enough of a pain as it is to tell users "you need to have libevent version X installed on OS Foo; you need libevent version Y on OS Bar, but version Z would be better for performance reasons." It would be inconvenient if we also had to tell users "If your version of libevent was built with certain compilation options, we can't use it. Sorry." So, deleting the functionality: not an option IMO. Moving functionality out of a library is always ugly business: every project that previously depended on the functionality being in the original library will now break, and you'll get a reputation as the kind of project that breaks backward compatibility all the time. Thus, if we're going to try to refactor libevent, we should make very very sure to avoid breaking older programs that are built to use existing libraries. I will not apply any patch for this that breaks backward compatibility. I'm no expert on cross-platform dynamic linkers, but is it feasible (with libtool or otherwise) to arrange things so that we can split libevent into separate libraries (libevent-core, libevent-http, etc), while at the same time ensuring that we don't break old code that searches for a "libevent" library with all the current libevent APIs? 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/20071001/419f8593/attachment.bin From rick.richardson at gmail.com Mon Oct 1 21:59:23 2007 From: rick.richardson at gmail.com (Rick R) Date: Mon Oct 1 21:59:27 2007 Subject: [Libevent-users] multiple read events triggered Message-ID: <9810b81b0710011859p6ee4c37asd5f89a2e14b2d2dd@mail.gmail.com> I am running libevent-dev on 32 bit Kubuntu. (whichever the verision is for kubuntu 7) I have made a simple socket reader in which I listen for new connections on a socket with EV_READ | EV_PERSIST which calls an acceptor callback. Inside that callback, I construct a new socket with accept and then put a data_reader type callback with EV_READ | EV_PERSIST as well. In the data_reader callback, I push the socket info into a work queue that is handled by a thread pool. This is where things get wierd, I can read read from the socket from the other thread just fine, but libevent often fires an additional 30-110 events, it's like it keeps firing the event until I read the data, is this the correct behavior? Note that when I leave the threadpool out and read the data immediately in the callback function, it does not cause multiple read events to occur. For performance reasons what I'd really like to do is let an available thread in the pool own/read/write a socket when it has data to be read. This allows the main thead to get back to accepting connections and handling read events. It also keeps me from having to copy the data out of the socket and put it into a mutexed buffer or copy to thread-local storage. Is this possible? Any help would be appreciated. Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071001/f3f5aa70/attachment.htm From lewislp at yahoo.com Mon Oct 1 22:08:23 2007 From: lewislp at yahoo.com (Larry Lewis) Date: Mon Oct 1 22:08:28 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents Message-ID: <676940.1059.qm@web51901.mail.re2.yahoo.com> The approach I've seen most often is to mark functions as deprecated and wait for a major release with expected API breakages to actually remove them. I doubt the inclusion of http and dns will be a deal-breaker for anyone, but if this is a sign of more and more code built on top of libevent to be included in the core library, it may discourage porting and usage. ----- Original Message ---- From: Nick Mathewson To: libevent-users@monkey.org Sent: Monday, October 1, 2007 7:20:04 PM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents On Mon, Oct 01, 2007 at 03:46:42PM -0700, Larry Lewis wrote: > +1 for the features not belonging in the library. I'd recommend > moving those features out into supporting libraries > (libevent-http/libevent-dns?) or even just using them as samples. > Most users would probably end up tweaking the http code anyways, in > my opinion. Here's an updated excerpt from the mail I sent Niels back in February, the last time people were talking about this: Niels wrote: > BTW, do you have an opinion about putting the more heavy-weight > libevent stuff into a separate library? Personally, I don't feel very strongly about this, but I'd vote for two libraries built from a single source package, or for two libraries. My reasoning against having only one library is this: I'd like to see the core of libevent get used by more projects, but the larger it becomes, the more work is required to maintain it, and port it to new platforms. I'd like to see the libevent core usable as a back-end by other general-purpose network utility libraries, like apr and glib and Twisted. These libraries already have their own implementations for things like http and rpc, though, and really don't need the ones in libevent. [...] My reason for preferring a single source package is that I'd like the I'd like the extended stuff to be available by default everywhere libevent is available, which is easiest if you have package maintainers start shipping two libraries from one package. (If you create a new source package, that will take more time to see any adoption.) [...] Of course, if you'd rather keep it as one package, I don't think my reasons above are really compelling. Factoring libraries is kind of a bike-shed problem; it's easy to form an opinion, and hard to show that any opinion is significantly better than any other. So, I don't really agree with the original patch either. As a maintainer for an application that uses libevent, it's enough of a pain as it is to tell users "you need to have libevent version X installed on OS Foo; you need libevent version Y on OS Bar, but version Z would be better for performance reasons." It would be inconvenient if we also had to tell users "If your version of libevent was built with certain compilation options, we can't use it. Sorry." So, deleting the functionality: not an option IMO. Moving functionality out of a library is always ugly business: every project that previously depended on the functionality being in the original library will now break, and you'll get a reputation as the kind of project that breaks backward compatibility all the time. Thus, if we're going to try to refactor libevent, we should make very very sure to avoid breaking older programs that are built to use existing libraries. I will not apply any patch for this that breaks backward compatibility. I'm no expert on cross-platform dynamic linkers, but is it feasible (with libtool or otherwise) to arrange things so that we can split libevent into separate libraries (libevent-core, libevent-http, etc), while at the same time ensuring that we don't break old code that searches for a "libevent" library with all the current libevent APIs? yrs, -- Nick Mathewson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071001/3bd0d261/attachment-0001.htm From rogerclark at gmail.com Tue Oct 2 02:49:28 2007 From: rogerclark at gmail.com (Roger Clark) Date: Tue Oct 2 02:49:33 2007 Subject: [Libevent-users] evdns C++ incompatibility Message-ID: <7a96dd2b0710012349hb5146bcu721807dfb049bfa8@mail.gmail.com> At least on my system, gcc complains about 'class' being used in these places in evdns.h: struct evdns_server_question { int type; int class; char name[1]; }; and int evdns_server_request_add_reply(struct evdns_server_request *req, int section, const char *name, int type, int class, int ttl, int datalen, int is_name, const char *data); It's probably a good idea to be on the safe side and change these identifiers to something else. I'm sure someone else will run into the problem eventually. -- Roger Clark rogerclark@gmail.com From coroberti at gmail.com Tue Oct 2 03:35:48 2007 From: coroberti at gmail.com (Robert Iakobashvili) Date: Tue Oct 2 03:35:50 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <676940.1059.qm@web51901.mail.re2.yahoo.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> Message-ID: <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> Larry, On 10/2/07, Larry Lewis wrote: > > The approach I've seen most often is to mark functions as deprecated and > wait for a major release with expected API breakages to actually remove > them. I doubt the inclusion of http and dns will be a deal-breaker for > anyone, but if this is a sign of more and more code built on top of libevent > to be included in the core library, it may discourage porting and usage. > Y are bringing a good point.. libevent is a great library for events demultiplexing, and I like it a lot. I would also doubt the addition of HTTP and DNS client stacks to the library itself, whereas they can be very good as the examples and testing applications. libcurl has developed a good API for its integration with libevent. libcurl project also maintains and develops a very good asynchronous DNS client library, called c-ares (a clone of ares). Could it be a better path to concentrate the community efforts on integration of c-ares and libcurl with libevent and to assist better to applications? For example, curl-loader is using libevent for demultiplexing and HTTP and FTP client stacks of libcurl to create a client side HTTP/HTTPS/FTP/FTPS testing framework (disclaimer - I am a maintainer of curl-loader, and, therefore, biased). Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ........................................................... http://curl-loader.sourceforge.net A web testing and traffic generation tool. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071002/f8472058/attachment.htm From nickm at freehaven.net Tue Oct 2 12:20:29 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Oct 2 12:21:05 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> Message-ID: <20071002162029.GE3927@totoro.wangafu.net> On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: [...] > libcurl has developed a good API for its integration with libevent. > libcurl project also maintains and develops a very good asynchronous DNS > client library, called c-ares (a clone of ares). > > Could it be a better path to concentrate the community efforts on > integration of c-ares and libcurl with libevent and to assist better > to applications? I would love somebody to get c-ares working right with libevent. I don't think this is a matter of "concentrating the community efforts", however: I think it's a matter of somebody stepping up to contribute the right patch to c-ares. The last time I checked, the main problems preventing c-ares from working optimally with libevent were: o C-ares had functions to fetch a list of sockets that needed to be read and written, but no way to make a callback happen when that list changes. This is fine for select() and poll(), but Libevent, on the other hand, wants to be told about _changes_ in socket state via event_add and event_del. Fixing this is probably a matter of adding a callback facility to c-ares. o The only way to tell c-ares about readable/writable sockets was via a function, ares_process(), that took an fd_set. This is suboptimal because 1) Libevent wants to alert applications about one socket at a time, and 2) Libevent is designed for situations where there are thousands of sockets, and making an fd_set with thousands of elements gives awful performance. Fixing this is probably a matter of adding an alternate way to invoke functionality of ares_process(). Of course, stuff may have changed since then; these problems may be solved. (I, _personally_, don't think I could use c-ares for my needs, since I need DNS server support as well as client support, and I'm under the impression that c-ares only provides the latter. But the more libraries that support libevent, the better.) 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/20071002/3eb83df9/attachment.bin From chris.brody at gmail.com Tue Oct 2 13:46:49 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Tue Oct 2 13:47:05 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <20071002162029.GE3927@totoro.wangafu.net> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> Message-ID: <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> On 10/2/07, Nick Mathewson wrote: > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > [...] > > libcurl has developed a good API for its integration with libevent. > > libcurl project also maintains and develops a very good asynchronous DNS > > client library, called c-ares (a clone of ares). > > > > Could it be a better path to concentrate the community efforts on > > integration of c-ares and libcurl with libevent and to assist better > > to applications? > > I would love somebody to get c-ares working right with libevent. I > don't think this is a matter of "concentrating the community efforts", > however: I think it's a matter of somebody stepping up to contribute > the right patch to c-ares. [...] I am happy to take a look in my free time, despite a lack of experience with libcurl & c-ares. I hope the HTTP & DNS parts of libevent can be officially built separately, regardless about where the source code is kept. Due to a lack of "official" RPM, my company is building libevent ourselves, so I would like to try Christopher's patches to Makefile.am & configure.in internally and report the results. I would like to suggest another idea, to automatically build both a "full" libevent library and a set of separated libevent parts, until the next major release. Chris From rick.richardson at gmail.com Tue Oct 2 14:58:48 2007 From: rick.richardson at gmail.com (Rick R) Date: Tue Oct 2 14:59:31 2007 Subject: [Libevent-users] evdns C++ incompatibility In-Reply-To: <7a96dd2b0710012349hb5146bcu721807dfb049bfa8@mail.gmail.com> References: <7a96dd2b0710012349hb5146bcu721807dfb049bfa8@mail.gmail.com> Message-ID: <9810b81b0710021158j39d68dc2tb0c2c4757bffb0d0@mail.gmail.com> While I agree that nowadays a common reserved c++ word shouldn't be in a header file, an easy enough workaround is to simply: extern "C" { #include #include <...> } which is my habit when pulling in any C files from C++; It has the added benefit of ensuring that the function names don't get mangled if you're doing some crazy linking or some such. On 10/2/07, Roger Clark wrote: > > At least on my system, gcc complains about 'class' being used in these > places in evdns.h: > > struct evdns_server_question { > int type; > int class; > char name[1]; > }; > > and > > int evdns_server_request_add_reply(struct evdns_server_request *req, > int section, const char *name, int type, int class, int ttl, int > datalen, int is_name, const char *data); > > It's probably a good idea to be on the safe side and change these > identifiers to something else. I'm sure someone else will run into the > problem eventually. > > -- > Roger Clark > rogerclark@gmail.com > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071002/c6dfa8b8/attachment.htm From 404emailnotfound at gmail.com Tue Oct 2 15:01:57 2007 From: 404emailnotfound at gmail.com (Matt Pearson) Date: Tue Oct 2 15:08:15 2007 Subject: [Libevent-users] multiple read events triggered In-Reply-To: <9810b81b0710011859p6ee4c37asd5f89a2e14b2d2dd@mail.gmail.com> References: <9810b81b0710011859p6ee4c37asd5f89a2e14b2d2dd@mail.gmail.com> Message-ID: <706b4240710021201i6aa83898t62a41d34e1abe732@mail.gmail.com> On 10/1/07, Rick R wrote: > In the data_reader callback, I push the socket info into a work queue that > is handled by a thread pool. This is where things get wierd, I can read read > from the socket from the other thread just fine, but libevent often fires an > additional 30-110 events, it's like it keeps firing the event until I read > the data, is this the correct behavior? This is the correct behavior. If you don't want to keep receiving read events on that file descriptor, you'll have to call event_del() or not use the EV_PERSIST flag. Then you'll have to figure out a way for the worker thread to tell the main thread to re-add the event. From rogerclark at gmail.com Tue Oct 2 15:18:15 2007 From: rogerclark at gmail.com (Roger Clark) Date: Tue Oct 2 15:18:24 2007 Subject: [Libevent-users] evdns C++ incompatibility In-Reply-To: <9810b81b0710021158j39d68dc2tb0c2c4757bffb0d0@mail.gmail.com> References: <7a96dd2b0710012349hb5146bcu721807dfb049bfa8@mail.gmail.com> <9810b81b0710021158j39d68dc2tb0c2c4757bffb0d0@mail.gmail.com> Message-ID: <7a96dd2b0710021218q64566bc7h28ad5d4a451e3edf@mail.gmail.com> Most of the header is already surrounded with extern "C", but not the offending part. Just wanted to give someone a heads up. On 10/2/07, Rick R wrote: > While I agree that nowadays a common reserved c++ word shouldn't be in a > header file, an easy enough workaround is to simply: > > extern "C" { > #include > #include <...> > } > > which is my habit when pulling in any C files from C++; > It has the added benefit of ensuring that the function names don't get > mangled if you're doing some crazy linking or some such. -- Roger Clark rogerclark@gmail.com From mail2arthur at gmail.com Tue Oct 2 15:26:19 2007 From: mail2arthur at gmail.com (arthur) Date: Tue Oct 2 15:26:36 2007 Subject: [Libevent-users] win32 build Message-ID: <004001c8052a$217a7d20$9b080f0a@usr.ingenico.loc> Hi All, Having been interested in libevent for a while, but just start to get dirty. Does libevent support Win32 any more. I have win2k with VS 6. Thanks. Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071002/22457d79/attachment.htm From nickm at freehaven.net Tue Oct 2 15:36:30 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Oct 2 15:36:36 2007 Subject: [Libevent-users] evdns C++ incompatibility In-Reply-To: <7a96dd2b0710021218q64566bc7h28ad5d4a451e3edf@mail.gmail.com> References: <7a96dd2b0710012349hb5146bcu721807dfb049bfa8@mail.gmail.com> <9810b81b0710021158j39d68dc2tb0c2c4757bffb0d0@mail.gmail.com> <7a96dd2b0710021218q64566bc7h28ad5d4a451e3edf@mail.gmail.com> Message-ID: <20071002193630.GG3927@totoro.wangafu.net> On Tue, Oct 02, 2007 at 03:18:15PM -0400, Roger Clark wrote: > Most of the header is already surrounded with extern "C", but not the > offending part. Just wanted to give someone a heads up. I just changed it, but it doesn't do any good. My understanding is that 'extern "C"' is only for linkage, and it doesn't keep the compiler from interpreting "class" as a C++ keyword. For example, the following C++ is invalid: extern "C" { struct s { int class; }; } So, it looks like we've got a few options here: 1) Rename the field and break old code that uses it. I think I may be the only user of this interface, so this wouldn't necessarily be a tragedy... but if there are others, we might cause them some grief. 2) Do some malarkey like struct evdns_server_request { /* ... */ #ifdef __cplusplus int dns_question_class; #else int class; #define dns_question_class class #endif /* ... */ }; so that we don't break existing C code that uses the field, but we start building under C++, and everybody can start migrating to the question_class field name. 3) Do something like struct evdns_server_request { /* ... */ #ifdef __cplusplus int dns_question_class; #else int class; #endif /* ... */ }; so that we break absolutely no old code, and C++ starts working. Of course, this would give the field a different name in C than in C++, and that's not so great. 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/20071002/013f067a/attachment.bin From nickm at freehaven.net Tue Oct 2 16:36:18 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Oct 2 16:36:36 2007 Subject: [Libevent-users] win32 build In-Reply-To: <004001c8052a$217a7d20$9b080f0a@usr.ingenico.loc> References: <004001c8052a$217a7d20$9b080f0a@usr.ingenico.loc> Message-ID: <20071002203618.GI3927@totoro.wangafu.net> On Tue, Oct 02, 2007 at 03:26:19PM -0400, arthur wrote: > Hi All, > > Having been interested in libevent for a while, but just start to > get dirty. Does libevent support Win32 any more. I have win2k with > VS 6. Hi! The most recent versions of libevent should work fine under Windows, but I've only tried building them with mingw recently, since I don't have a VC license. If there are compilation errors or warnings with VC, please let us know. peace, -- 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/20071002/fd98775c/attachment.bin From mail2arthur at gmail.com Tue Oct 2 18:21:04 2007 From: mail2arthur at gmail.com (arthur zhang) Date: Tue Oct 2 18:21:09 2007 Subject: [Libevent-users] win32 build In-Reply-To: <20071002203618.GI3927@totoro.wangafu.net> References: <004001c8052a$217a7d20$9b080f0a@usr.ingenico.loc> <20071002203618.GI3927@totoro.wangafu.net> Message-ID: <7000da8e0710021521g6e2e6b84v71e92e3060a3c6f1@mail.gmail.com> Thanks Nick. What I did (with MSVC6 on Win2k): 1. load libevent 1.3e 2. open libevent.dsw, but nothing listed in the workspace. This is fixed by edit all four dsp files and the dsw file then save all in DOS format. 3. try to compile event.c, error: can't open sys/time.h, then I copy sys/_time.h to time.h (??) 4. can't open stdint.h, makeup one from http://msinttypes.googlecode.com/svn/trunk/stdint.h 5. undefine: __func__ (line 212), VERSION (line 916) 6. add HAVE_CONFIG_H to prj (??) 7. undefine: gettimeofday(line 175) and __FUNCTION__ (line 212) 8. #define __FUNCTION__ __LINE__ 9. compile event.c with 0 err, 2 warning (still has no gettimeofday ) 10 asked to this list. Since my target platform is Solaris, now I am working on my Ubuntu to play/dev, but I'd like to test MSVC build if any patch/update is available. Thanks. Arthur On 10/2/07, Nick Mathewson wrote: > > On Tue, Oct 02, 2007 at 03:26:19PM -0400, arthur wrote: > > Hi All, > > > > Having been interested in libevent for a while, but just start to > > get dirty. Does libevent support Win32 any more. I have win2k with > > VS 6. > > Hi! The most recent versions of libevent should work fine under > Windows, but I've only tried building them with mingw recently, since > I don't have a VC license. If there are compilation errors or > warnings with VC, please let us know. > > peace, > -- > Nick Mathewson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071002/6941dd59/attachment.htm From 404emailnotfound at gmail.com Tue Oct 2 19:37:43 2007 From: 404emailnotfound at gmail.com (Matt Pearson) Date: Tue Oct 2 19:37:52 2007 Subject: [Libevent-users] multiple read events triggered In-Reply-To: <9810b81b0710021320g631577a7mae3cd02893c6dcd5@mail.gmail.com> References: <9810b81b0710011859p6ee4c37asd5f89a2e14b2d2dd@mail.gmail.com> <706b4240710021201i6aa83898t62a41d34e1abe732@mail.gmail.com> <9810b81b0710021320g631577a7mae3cd02893c6dcd5@mail.gmail.com> Message-ID: <706b4240710021637u6b3933f7sf9871a54132f853@mail.gmail.com> Please reply to the whole list in the future. epoll actually supports (according to its man page) both this style of notification and edge-triggered, where it tells you when a read is first available and it's up to you to keep reading until read() fails with errno = EAGAIN. However, since not all notification mechanisms support this kind of behavior, libevent uses the one that gives consistent behavior across backends. Besides, in many situations, this kind of behavior is more useful. On 10/2/07, Rick R wrote: > Thanks for the heads-up on that. Do you happen to know if it's a feature of > libevent alone, or is it a by-product of epoll specifically? From slamb at slamb.org Tue Oct 2 21:18:43 2007 From: slamb at slamb.org (Scott Lamb) Date: Tue Oct 2 21:18:53 2007 Subject: [Libevent-users] multiple read events triggered In-Reply-To: <706b4240710021637u6b3933f7sf9871a54132f853@mail.gmail.com> References: <9810b81b0710011859p6ee4c37asd5f89a2e14b2d2dd@mail.gmail.com> <706b4240710021201i6aa83898t62a41d34e1abe732@mail.gmail.com> <9810b81b0710021320g631577a7mae3cd02893c6dcd5@mail.gmail.com> <706b4240710021637u6b3933f7sf9871a54132f853@mail.gmail.com> Message-ID: <4702EDF3.1010402@slamb.org> Matt Pearson wrote: > Please reply to the whole list in the future. > > epoll actually supports (according to its man page) both this style of > notification and edge-triggered, where it tells you when a read is > first available and it's up to you to keep reading until read() fails > with errno = EAGAIN. However, since not all notification mechanisms > support this kind of behavior, libevent uses the one that gives > consistent behavior across backends. Besides, in many situations, > this kind of behavior is more useful. I remember seeing a while ago a patch that would optionally use the other behavior. Not sure if it ever made it to this list, but google finds it elsewhere: https://webmail.iro.umontreal.ca/pipermail/gambit-list/2005-August/000367.html if "event_abilities() & EV_ABILITY_EDGE" is true, you could use EV_READ|EV_WRITE|EV_PERSIST|EV_EDGE or the like. From slamb at slamb.org Tue Oct 2 22:30:17 2007 From: slamb at slamb.org (Scott Lamb) Date: Tue Oct 2 22:32:32 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <20071002162029.GE3927@totoro.wangafu.net> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> Message-ID: <4702FEB9.3010706@slamb.org> Nick Mathewson wrote: > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > [...] >> libcurl has developed a good API for its integration with libevent. >> libcurl project also maintains and develops a very good asynchronous DNS >> client library, called c-ares (a clone of ares). >> >> Could it be a better path to concentrate the community efforts on >> integration of c-ares and libcurl with libevent and to assist better >> to applications? > > I would love somebody to get c-ares working right with libevent. I > don't think this is a matter of "concentrating the community efforts", > however: I think it's a matter of somebody stepping up to contribute > the right patch to c-ares. > > The last time I checked, the main problems preventing c-ares from > working optimally with libevent were: > o C-ares had functions to fetch a list of sockets that needed > to be read and written, but no way to make a callback happen when > that list changes. This is fine for select() and poll(), but > Libevent, on the other hand, wants to be told about _changes_ in > socket state via event_add and event_del. > > Fixing this is probably a matter of adding a callback facility to > c-ares. It already exists: struct ares_options options; ... options.sock_state_cb = foo; ... ... = ares_init_options(..., &options, ...|ARES_OPT_SOCK_STATE_CB); > o The only way to tell c-ares about readable/writable sockets was > via a function, ares_process(), that took an fd_set. This is > suboptimal because 1) Libevent wants to alert applications about > one socket at a time, and 2) Libevent is designed for situations > where there are thousands of sockets, and making an fd_set with > thousands of elements gives awful performance. > > Fixing this is probably a matter of adding an alternate way to > invoke functionality of ares_process(). Also exists: void ares_process_fd(ares_channel channel, ares_socket_t read_fd, ares_socket_t write_fd); > > Of course, stuff may have changed since then; these problems may be > solved. Yup. > > (I, _personally_, don't think I could use c-ares for my needs, since I > need DNS server support as well as client support, and I'm under the > impression that c-ares only provides the latter. But the more > libraries that support libevent, the better.) > > yrs, > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From slamb at slamb.org Tue Oct 2 23:07:11 2007 From: slamb at slamb.org (Scott Lamb) Date: Tue Oct 2 23:08:41 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> Message-ID: <4703075F.1070202@slamb.org> Chris Brody-GMail wrote: > I would like to suggest another idea, to automatically build both a > "full" libevent library and a set of separated libevent parts, until > the next major release. +1 I think the -levent-core -lev-http approach makes sense, but (quoting Nick Mathewson's email): > I'm no expert on cross-platform dynamic linkers, but is it feasible > (with libtool or otherwise) to arrange things so that we can split > libevent into separate libraries (libevent-core, libevent-http, etc), > while at the same time ensuring that we don't break old code that > searches for a "libevent" library with all the current libevent APIs? IIRC, Chris Brody's suggestion is the only way to do that, as library dependencies are not transitive in some situations (static libraries, and dynamic libraries some platforms). From slamb at slamb.org Tue Oct 2 23:14:32 2007 From: slamb at slamb.org (Scott Lamb) Date: Tue Oct 2 23:15:51 2007 Subject: [Libevent-users] Question: Library naming In-Reply-To: <46F8DF1B.4040000@sun.com> References: <46F8DF1B.4040000@sun.com> Message-ID: <47030918.7050803@slamb.org> Trond Norbye wrote: > I thought that it was normal to name the libraries like > lib.so... (eg: libevent.so.1.3.4) and create > symbolic links so the application may pick up the newest version of the > library (with the correct ABI) without re-linking the application. As did I, and I've wondered about this for a while. > > Is there a good reason for not doing so? Nick, have you given any thought to this? I'm surprised to see your arguments about preserving compatibility considering that each client application needs to be relinked to pick up libevent bugfixes, and many versions of libevent kept around on systems where they haven't been. libevent's APIs (existing functions' signatures + "struct event" layout) changes infrequently enough that I think most releases could just be a minor version bump. From nickm at freehaven.net Tue Oct 2 23:24:20 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Tue Oct 2 23:24:24 2007 Subject: [Libevent-users] Question: Library naming In-Reply-To: <47030918.7050803@slamb.org> References: <46F8DF1B.4040000@sun.com> <47030918.7050803@slamb.org> Message-ID: <20071003032420.GO3927@totoro.wangafu.net> On Tue, Oct 02, 2007 at 08:14:32PM -0700, Scott Lamb wrote: > Trond Norbye wrote: > > I thought that it was normal to name the libraries like > > lib.so... (eg: libevent.so.1.3.4) and create > > symbolic links so the application may pick up the newest version of the > > library (with the correct ABI) without re-linking the application. > > As did I, and I've wondered about this for a while. > > > > > Is there a good reason for not doing so? > > Nick, have you given any thought to this? I'm surprised to see your > arguments about preserving compatibility considering that each client > application needs to be relinked to pick up libevent bugfixes, and many > versions of libevent kept around on systems where they haven't been. > libevent's APIs (existing functions' signatures + "struct event" layout) > changes infrequently enough that I think most releases could just be a > minor version bump. Agreed; I believe the only reason that neither Niels or I has made the change is that neither of us knows libtool very well. It would be good if somebody would submit a patch to do the right thing, and explain which numbers we need to bump in the future when the version changes and/or when we lose backward compatibility. With any luck, it's as simple as messing with libevent_la_LDFLAGS in in Makefile.am. 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/20071002/df62cf45/attachment.bin From nickm at freehaven.net Wed Oct 3 00:20:20 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Wed Oct 3 00:21:07 2007 Subject: [Libevent-users] [patch] 1.3 revision strsep last i post have a mistake In-Reply-To: <882104.24061.qm@web15707.mail.cnb.yahoo.com> References: <882104.24061.qm@web15707.mail.cnb.yahoo.com> Message-ID: <20071003042020.GD13242@totoro.wangafu.net> On Sun, Sep 30, 2007 at 10:52:50AM +0800, claris_chen-news@yahoo.com.cn wrote: > > I am pretty sorry that the last patch I posted is not correct. > > this one will sovlve it. Thanks; I've checked in a version of this patch. 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/20071003/08921df5/attachment.bin From chris.brody at gmail.com Wed Oct 3 06:12:22 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Wed Oct 3 06:12:26 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> Message-ID: <7365f28e0710030312t456a5c8fr20ebebb18393305@mail.gmail.com> On 10/3/07, Scott Lamb wrote: [...] > I think the -levent-core -lev-http approach makes sense, but (quoting > Nick Mathewson's email): [...] I hope this will be possible. We actually have one process that only uses "event-core" and another process that also needs "ev-http". > Due to a lack of "official" RPM, my company is building libevent > ourselves, so I would like to try Christopher's patches to Makefile.am > & configure.in internally and report the results. I have made a patch based on the original idea, to patch the automake files and a few tests and uploaded them to: * http://chris.brody.googlepages.com/libevent_ac_cjb_20071002.diff.txt * http://chris.brody.googlepages.com/libevent_test_cjb_20071002.diff.txt However, this does not help us since different processes use different parts. In addition, the original proposal makes a separate evbuffer.h header file. Such modular design is very important for object-oriented programming. For example: http://repo.or.cz/w/eventxx.git From dave at powerset.com Thu Oct 4 13:17:41 2007 From: dave at powerset.com (Dave Simpson) Date: Thu Oct 4 13:31:24 2007 Subject: [Libevent-users] evdns and multi-threaded environments Message-ID: I've been using the event_base API to allow several worker threads to run an event loop. I'd like to use the asynchronous dns from evdns, but from what I can see, it isn't thread safe. Any thoughts on this? >From looking at the code, two big changes need to be made: 1) allow API users to specify an event_base for any call that interacts with the libevent system. 2) move most of the global variables/state into a struct and provide an init call that returns the struct as a handle that can later be passed into most of the API calls. That version of init could take the event_base to be used. Any thoughts on this? -Dave From re.seanm at gmail.com Fri Oct 5 13:30:15 2007 From: re.seanm at gmail.com (s m) Date: Fri Oct 5 13:30:50 2007 Subject: [Libevent-users] evhttp help Message-ID: <2ad3bd040710051030l1d93a32xae6356dce251a8e@mail.gmail.com> Hi everyone- I'm evaluating using libevent on a project I'm working on. I'm having some issues with my test program using evhttp. It seems to leak memory. I'm feeding it 100 requests per second. Using ps I can see its memory usage continually grow, until it crashes from not being able to malloc/calloc/etc.. I ran my app in valgrind, it didn't find any lost blocks. I'm stumped. Perhaps I'm forgetting to free some resource using the api? Not sure what's going on. Below is the pseudo-ish code for my app. Any insight would be *greatly* appreciated. I'm running libevent-1.3e on Debian sarge with a 2.4 kernel. main() { httpd = evhttp_start("0.0.0.0",8080); evhttp_set_timeout(httpd, 5); evhttp_set_cb(httpd, "/log", log, NULL); event_dispatch(); } and in log()- void log(struct evhttp_request* req, void* arg) { char msg[] = "This is a test"; evbuffer* buf = evbuffer_new(); if (buf) { evbuffer_add(buf, msg, strlen(msg)); evhttp_send_reply(req, HTTP_OK, "OK", buf); evhttp_send_reply_end(req); evbuffer_free(buf); } } From mail2arthur at gmail.com Tue Oct 9 11:06:21 2007 From: mail2arthur at gmail.com (arthur zhang) Date: Tue Oct 9 12:40:19 2007 Subject: [Libevent-users] file io Message-ID: <7000da8e0710090806q757c5eb3ub232a8094ac9feaf@mail.gmail.com> Hi All, As my understanding, with libevent, any io should be non_blocking, and here comes my dumb q;-) I want log stuffs(trace) to a disk file in my comm callback, so I open a file like below, but I didn't get any write event to call back. I am using Ubuntu Dapper and my target system is Solaris 10. Using stdout worked. Thanks. Arthur --------------------- fdmsg = open(glbCfg.msg_file, O_WRONLY|O_CREAT|O_APPEND|O_NONBLOCK, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); if(fdmsg<0) { err(-1, "Can't open file to write %s", glbCfg.msg_file); } //fdmsg = fileno(stdout); if(fcntl(fdmsg, F_SETFL, O_NONBLOCK)==-1) { err(-1, "fcntl"); } rcd = io_new_sink(fdmsg); printf("rcd %p %d\n", rcd, fdmsg); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071009/db7d73a5/attachment.htm From cfk.quan at gmail.com Tue Oct 9 08:16:26 2007 From: cfk.quan at gmail.com (Quan Sun) Date: Tue Oct 9 12:44:30 2007 Subject: [Libevent-users] Multithreads event_add problem Message-ID: Hi, These days I'm working on a web client project. The design is rather simple, and I use two threads. One thread creates sockets, with a given time-varing speed, then these sockets are passed to second thread. The second thread is a event_dispatch(), it perform all the actual work. My question is, what is the best method to pass events between thread? I used event_add in first thread, and these two threads share event. But it seems that libevent is leaking fds in this case, I've read some of 1.2a's codes, libevent itself does not have thread lock in event_add. -- Quan Sun From cfk.quan at gmail.com Tue Oct 9 08:52:47 2007 From: cfk.quan at gmail.com (Quan Sun) Date: Tue Oct 9 13:09:00 2007 Subject: [Libevent-users] Re: Multithreads event_add problem In-Reply-To: References: Message-ID: SGksCgpJJ3ZlIGFkZCBldmVudF9iYXNlX3NldCBiZWZvcmUgZXZlbnRfYWRkLCBub3cgaXQgc2Vl bXMgdGhhdCBpdCB3b3Jrcy4KCk9uIDEwLzkvMDcsIFF1YW4gU3VuIDxjZmsucXVhbkBnbWFpbC5j b20+IHdyb3RlOgo+IEhpLAo+Cj4gVGhlc2UgZGF5cyBJJ20gd29ya2luZyBvbiBhIHdlYiBjbGll bnQgcHJvamVjdC4gVGhlIGRlc2lnbiBpcyByYXRoZXIKPiBzaW1wbGUsIGFuZCBJIHVzZSB0d28g dGhyZWFkcy4KPgo+IE9uZSB0aHJlYWQgY3JlYXRlcyBzb2NrZXRzLCB3aXRoIGEgZ2l2ZW4gdGlt ZS12YXJpbmcgc3BlZWQsIHRoZW4gdGhlc2UKPiBzb2NrZXRzIGFyZSBwYXNzZWQgdG8gc2Vjb25k IHRocmVhZC4gVGhlIHNlY29uZCB0aHJlYWQgaXMgYQo+IGV2ZW50X2Rpc3BhdGNoKCksIGl0IHBl cmZvcm0gYWxsIHRoZSBhY3R1YWwgd29yay4KPgo+IE15IHF1ZXN0aW9uIGlzLCB3aGF0IGlzIHRo ZSBiZXN0IG1ldGhvZCB0byBwYXNzIGV2ZW50cyBiZXR3ZWVuIHRocmVhZD8KPiBJIHVzZWQgZXZl bnRfYWRkIGluIGZpcnN0IHRocmVhZCwgYW5kIHRoZXNlIHR3byB0aHJlYWRzIHNoYXJlIGV2ZW50 Lgo+IEJ1dCBpdCBzZWVtcyB0aGF0IGxpYmV2ZW50IGlzIGxlYWtpbmcgZmRzIGluIHRoaXMgY2Fz ZSwgSSd2ZSByZWFkIHNvbWUKPiBvZiAxLjJhJ3MgY29kZXMsIGxpYmV2ZW50IGl0c2VsZiBkb2Vz IG5vdCBoYXZlIHRocmVhZCBsb2NrIGluCj4gZXZlbnRfYWRkLgo+Cj4gLS0KPgo+IFF1YW4gU3Vu Cj4KCgotLSAKLS0KysC957rctPOjrCDKsbzkutyzpKGjCgpRdWFuIFN1bgo= From william at 25thandClement.com Tue Oct 9 13:25:10 2007 From: william at 25thandClement.com (William Ahern) Date: Tue Oct 9 13:35:18 2007 Subject: [Libevent-users] file io In-Reply-To: <7000da8e0710090806q757c5eb3ub232a8094ac9feaf@mail.gmail.com> References: <7000da8e0710090806q757c5eb3ub232a8094ac9feaf@mail.gmail.com> Message-ID: <20071009172510.GC10630@wilbur.25thandClement.com> On Tue, Oct 09, 2007 at 11:06:21AM -0400, arthur zhang wrote: > Hi All, > > As my understanding, with libevent, any io should be non_blocking, and here > comes my dumb q;-) > > I want log stuffs(trace) to a disk file in my comm callback, so I open a > file like below, but I didn't get any write event to call back. I am using > Ubuntu Dapper and my target system is Solaris 10. 1) You can't do non-blocking file I/O in Unix using the standard interfaces. You need to use a horrible and poorly implemented interfaces like POSIX Asynchronous I/O, which is impossible to use with libevent. 2) A file descriptor (to a realfile) will _always_ poll as ready for reading or writing. (The logic being, even though the disk might be slow, it's still always available for I/O--the disk is one gigantic buffer.) Thus, if your code was written properly your complaint should have been that you got an endless succession of write readiness callbacks suspicously lacking any gap. > Using stdout worked. If stdout was a pipe, then it would work. Thus, you could shamefully (but with good reason) pipe to cat, and redirect cat's stdout to a file. From william at opensource4you.com Tue Oct 9 13:30:49 2007 From: william at opensource4you.com (william@opensource4you.com) Date: Tue Oct 9 13:37:37 2007 Subject: [Libevent-users] problem with Sigint and http events Message-ID: <55092.81.245.133.121.1191951049.squirrel@mail.opensource4you.com> Hi, I'm not a good expert of C, but trying to build a simple example using libevent. I've succesfully build a very simple http server with the stupid "Hello World" message. Now I'm trying to capture a SIGINT as shown in "sample/signal-test.c" present in the libevent tar file. Unfortunately, I receive a segmentation fault " *** glibc detected *** ./test: double free or corruption (!prev): 0x0804f1e0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7e54c06] /lib/libc.so.6(cfree+0x89)[0xb7e568c9] /usr/lib/libevent-1.3d.so.1(evhttp_free+0x4f)[0xb7f5933f] ./test(signal_cb+0x55)[0x8048995] /usr/lib/libevent-1.3d.so.1(event_base_loop+0x242)[0xb7f56832] /usr/lib/libevent-1.3d.so.1(event_loop+0x29)[0xb7f56ac9] /usr/lib/libevent-1.3d.so.1(event_dispatch+0x1e)[0xb7f56aee] ./test[0x804891a] /lib/libc.so.6(__libc_start_main+0xe0)[0xb7e04f90] " Does some can exaplain it ? If I remove the http_free(http_server) command, the process never stop any more ;-(. I need to use a "kill -9" to stop it. Why this is so ? is there some event not yet complete ? Thanks. ANNEXE: -------- test.c: ------- 1: #include 2: #ifdef WIN32 3: #include 4: #include 5: #endif 6: 7: #ifdef HAVE_CONFIG_H 8: #include "config.h" 9: #endif 10: 11: #include 12: #include 13: #ifdef HAVE_SYS_TIME_H 14: #include 15: #endif 16: #include 17: #ifndef WIN32 18: #include 19: #include 20: #include 21: #endif 22: #include 23: #include 24: #include 25: #include 26: #include 27: #include 28: 29: #include "event.h" 30: #include "evhttp.h" 31: #include "log.h" 32: #include "http-internal.h" 33: 34: struct evhttp* httpd; 35: 36: void root_handler( struct evhttp_request *req, void *arg) 37: { 38: struct evbuffer *evb=evbuffer_new(); 39: evbuffer_add_printf(evb, "Hello World!"); 40: printf("Request from %s:", req->remote_host); 41: printf("%i\n", req->remote_port); 42: evhttp_send_reply(req, HTTP_OK, "OK", evb); 43: evbuffer_free(evb); 44: } 45: 46: 47: int called = 0; 48: 49: void 50: signal_cb(int fd, short event, void *arg) 51: { 52: struct event *signal = arg; 53: 54: printf("got signal %d\n", EVENT_SIGNAL(signal)); 55: if (called >= 2) 56: event_del(signal); 57: evhttp_free(httpd); 58: called++; 59: } 60: 61: 62: 63: int main(int argc, char **argv) 64: { 65: struct event signal_int; 66: event_init(); 67: event_set(&signal_int, SIGINT, EV_SIGNAL|EV_PERSIST, signal_cb, &signal_int); 68: event_add(&signal_int, NULL); 69: httpd=evhttp_start("0.0.0.0", 8080); 70: evhttp_set_cb(httpd, "/", root_handler, NULL); 71: printf("start dispatch\n"); 72: event_dispatch(); 73: printf("stop dispatch\n"); 74: return 0; 75: } 76: compilation commands: --------------------- gcc -g -O3 -Wall -Wstrict-prototypes -fPIC -I/var/abs/local/libevent/src/libevent-1.3b -I/usr/include/python2.5 -c test.c -o test.o gcc -g -O2 -Wall -o test test.o -levent -lnsl -lrt -lresolv From mail2arthur at gmail.com Tue Oct 9 14:13:29 2007 From: mail2arthur at gmail.com (arthur zhang) Date: Tue Oct 9 14:13:46 2007 Subject: [Libevent-users] file io In-Reply-To: <20071009172510.GC10630@wilbur.25thandClement.com> References: <7000da8e0710090806q757c5eb3ub232a8094ac9feaf@mail.gmail.com> <20071009172510.GC10630@wilbur.25thandClement.com> Message-ID: <7000da8e0710091113l78c9e2b8mda527a40595bafde@mail.gmail.com> Thanks William, you tell me (and help me) a lot. So looks I will output the trace to a socket port and create a receiver to write it to disk. Cheers, Arthur On 10/9/07, William Ahern wrote: > > On Tue, Oct 09, 2007 at 11:06:21AM -0400, arthur zhang wrote: > > Hi All, > > > > As my understanding, with libevent, any io should be non_blocking, and > here > > comes my dumb q;-) > > > > I want log stuffs(trace) to a disk file in my comm callback, so I open a > > file like below, but I didn't get any write event to call back. I am > using > > Ubuntu Dapper and my target system is Solaris 10. > > 1) You can't do non-blocking file I/O in Unix using the standard > interfaces. > You need to use a horrible and poorly implemented interfaces like POSIX > Asynchronous I/O, which is impossible to use with libevent. > > 2) A file descriptor (to a realfile) will _always_ poll as ready for > reading > or writing. (The logic being, even though the disk might be slow, it's > still always available for I/O--the disk is one gigantic buffer.) Thus, > if your code was written properly your complaint should have been that > you got an endless succession of write readiness callbacks suspicously > lacking any gap. > > > Using stdout worked. > > If stdout was a pipe, then it would work. Thus, you could shamefully (but > with good reason) pipe to cat, and redirect cat's stdout to a file. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071009/f6ea0a7d/attachment.htm From wouter at nlnetlabs.nl Wed Oct 10 04:39:51 2007 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed Oct 10 04:40:09 2007 Subject: [Libevent-users] problem with Sigint and http events In-Reply-To: <55092.81.245.133.121.1191951049.squirrel@mail.opensource4you.com> References: <55092.81.245.133.121.1191951049.squirrel@mail.opensource4you.com> Message-ID: <470C8FD7.9070403@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well its catching the signal allright, but you do the wrong things in your signal handler. The event_del and _free calls are probably not good to call from a signal handler. I guess the dispatch after that fails. You could call exit(0), or event_loopexit(0); right after the printf. Best regards, Wouter william@opensource4you.com wrote: > Hi, > > I'm not a good expert of C, but trying to build a simple example using > libevent. > > I've succesfully build a very simple http server with the stupid "Hello > World" message. > > Now I'm trying to capture a SIGINT as shown in "sample/signal-test.c" > present in the libevent tar file. > > Unfortunately, I receive a segmentation fault > " > *** glibc detected *** ./test: double free or corruption (!prev): -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHDI/XkDLqNwOhpPgRAqG7AKCVzg2bBvDsUh/CULtnXFUtpW9WDACgtNoG 68q3saH1loTQ0YIW8anccvk= =+Xe0 -----END PGP SIGNATURE----- From vsevolod at highsecure.ru Fri Oct 12 09:41:44 2007 From: vsevolod at highsecure.ru (Vsevolod Stakhov) Date: Fri Oct 12 09:42:04 2007 Subject: [Libevent-users] MAX_ADDRS is too low in evdns Message-ID: <200710121741.44308.vsevolod@highsecure.ru> Now evdns can only parse DNS replies that contains up to 4 addresses. This is ruled by MAX_ADDRS macro in evdns.c I think this limit is not enough for normal using of evdns, for example: >host py-out-1314.google.com | wc -l 8 So I think it would be good to increase this constant up to some reasonable value (I've tested evdns with MAX_ADDRS=32). From william at opensource4you.com Sun Oct 14 05:22:01 2007 From: william at opensource4you.com (william@opensource4you.com) Date: Sun Oct 14 05:22:24 2007 Subject: [Libevent-users] How to make a Generic handler ? Message-ID: <34350.91.176.148.79.1192353721.squirrel@mail.opensource4you.com> I would like to know the best way to write a generic handler to dispatch my static files located at /static ? Indeed, evhttp_set_cb needs to have the complete uri. For example, /static/img/home.jpg. On the orther hand evhttp_set_gencb is generic for the all uri. This is a of nice way to display "this page is not accessible". I'm looking an handler that will manage all my static files. In other words, when the requestor detect an uri starting by "/static", he should always call the same handler. Is there someone who already have think about this ? How have you solve it decently ? Thanks From william at opensource4you.com Sun Oct 14 14:10:44 2007 From: william at opensource4you.com (william@opensource4you.com) Date: Sun Oct 14 14:11:06 2007 Subject: [Libevent-users] How to make a Generic handler ? In-Reply-To: <34350.91.176.148.79.1192353721.squirrel@mail.opensource4you.com> References: <34350.91.176.148.79.1192353721.squirrel@mail.opensource4you.com> Message-ID: <52895.91.176.148.79.1192385444.squirrel@mail.opensource4you.com> By looking into the libevent code, I think that what must be changed is the following (evhttp_handle_request in http.c): /* Test for different URLs */ TAILQ_FOREACH(cb, &http->callbacks, next) { int res; char *p = strchr(req->uri, '?'); if (p == NULL) res = strcmp(cb->what, req->uri) == 0; else res = strncmp(cb->what, req->uri, - (size_t)(p - req->uri)) == 0; + len(cb->what) == 0; if (res) { (*cb->cb)(req, cb->cbarg); return; } } That way by doing this: evhttp_set_cb(http_server, "/static/", static_handler, NULL); the following uri will call static_handler: - /static/img/home.jpeg - /static/css/main.css If I'm not wrong, how can I implement such modification(I'm not a C expert) ? Is there a way in C (like we have in python or java) a way to rewrite a methode of a share library ? Thanks for your help. William > I would like to know the best way to write a generic handler to dispatch > my static files located at /static ? > > Indeed, evhttp_set_cb needs to have the complete uri. For example, > /static/img/home.jpg. > On the orther hand evhttp_set_gencb is generic for the all uri. This is a > of nice way to display "this page is not accessible". > > I'm looking an handler that will manage all my static files. In other > words, when the requestor detect an uri starting by "/static", he should > always call the same handler. > > > Is there someone who already have think about this ? > How have you solve it decently ? > > Thanks > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From william at opensource4you.com Tue Oct 16 06:39:16 2007 From: william at opensource4you.com (william@opensource4you.com) Date: Tue Oct 16 06:39:43 2007 Subject: [Libevent-users] How to make a Generic handler ? In-Reply-To: <52895.91.176.148.79.1192385444.squirrel@mail.opensource4you.com> References: <34350.91.176.148.79.1192353721.squirrel@mail.opensource4you.com> <52895.91.176.148.79.1192385444.squirrel@mail.opensource4you.com> Message-ID: <47696.87.65.20.107.1192531156.squirrel@mail.opensource4you.com> I answer my own question ;-). Here after the correct modification to make in evhttp_handle_request. in http.c->evhttp_handle_request " if (p == NULL) - res = strcmp(cb->what, req->uri) == 0; + res = strncmp(cb->what, req->uri, strlen(cb->what)) == 0; else res = strncmp(cb->what, req->uri, - (size_t)(p - req->uri)) == 0; + strlen(cb->what)) == 0; if (res) { (*cb->cb)(req, cb->cbarg); " I've included it within my python bridge to libevent and it works great. (I'm progressing with C). I'm already able to use python function as http_event callbacks. Next steps is to make them WSGI compliant ;-). William > > By looking into the libevent code, I think that what must be changed is > the following (evhttp_handle_request in http.c): > > /* Test for different URLs */ > TAILQ_FOREACH(cb, &http->callbacks, next) { > int res; > char *p = strchr(req->uri, '?'); > if (p == NULL) > res = strcmp(cb->what, req->uri) == 0; > else > res = strncmp(cb->what, req->uri, > - (size_t)(p - req->uri)) == 0; > + len(cb->what) == 0; > if (res) { > (*cb->cb)(req, cb->cbarg); > return; > } > } > > > > That way by doing this: > evhttp_set_cb(http_server, "/static/", static_handler, NULL); > the following uri will call static_handler: > - /static/img/home.jpeg > - /static/css/main.css > > > > If I'm not wrong, how can I implement such modification(I'm not a C > expert) ? > Is there a way in C (like we have in python or java) a way to rewrite a > methode of a share library ? > > > Thanks for your help. > > William > > > > > > > >> I would like to know the best way to write a generic handler to dispatch >> my static files located at /static ? >> >> Indeed, evhttp_set_cb needs to have the complete uri. For example, >> /static/img/home.jpg. >> On the orther hand evhttp_set_gencb is generic for the all uri. This is >> a >> of nice way to display "this page is not accessible". >> >> I'm looking an handler that will manage all my static files. In other >> words, when the requestor detect an uri starting by "/static", he should >> always call the same handler. >> >> >> Is there someone who already have think about this ? >> How have you solve it decently ? >> >> Thanks >> >> _______________________________________________ >> Libevent-users mailing list >> Libevent-users@monkey.org >> http://monkey.org/mailman/listinfo/libevent-users >> >> > > > > From dolmens at gmail.com Wed Oct 17 04:36:15 2007 From: dolmens at gmail.com (Sun Yi-Ming) Date: Wed Oct 17 04:36:31 2007 Subject: [Libevent-users] =?utf-8?q?event=2Eh=3A214=3A_error=3A_expected_?= =?utf-8?q?specifier-qualifier-list_before_=E2=80=98u=5Fchar?= =?utf-8?b?4oCZLWJ1Zz8=?= Message-ID: <6893328f0710170136w91c8704q9ee5f2f68e8c0efc@mail.gmail.com> Hi guys, I try to compile libevent-1.3e on my debian etch box, and got an error message which is "event.h:214: error: expected specifier-qualifier-list before 'u_char'". Is it a bug or did I do something wrong. btw, if i put an statement " typedef unsigned char u_char;" before include event.h, the compile goes smoothly. #include // typedef unsigned char u_char; #include int main() { return 0; } -- Sincerely, ??? Simon Sun -- Be a man with simple interface. From chris.brody at gmail.com Wed Oct 17 05:19:02 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Wed Oct 17 05:19:13 2007 Subject: =?GB2312?B?UmU6IFtMaWJldmVudC11c2Vyc10gZXZlbnQuaDoyMTQ6IGVycm9yOiBleHBlY3Q=?= =?GB2312?B?ZWQgc3BlY2lmaWVyLXF1YWxpZmllci1s?= =?GB2312?B?aXN0IGJlZm9yZSChrnVfY2hhcqGvLWJ1Zz8=?= In-Reply-To: <6893328f0710170136w91c8704q9ee5f2f68e8c0efc@mail.gmail.com> References: <6893328f0710170136w91c8704q9ee5f2f68e8c0efc@mail.gmail.com> Message-ID: <7365f28e0710170219q137e3838p1ba8252648ba60b0@mail.gmail.com> UGxlYXNlIGFkZCAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+IGJlZm9yZSAjaW5jbHVkZSA8ZXZlbnQu aD4uCgpUaGUgQysrIGV2ZW50eHggbGlicmFyeSAoaHR0cDovL3JlcG8ub3IuY3ovdy9ldmVudHh4 LmdpdCkgZG9lcyB0aGlzIGluCml0cyB3cmFwcGVyIGhlYWRlciBmaWxlLgoKSSBob3BlIHRoaXMg cmVxdWlyZW1lbnQgd2lsbCBlaXRoZXIgYmUgY2xlYXJseSBkb2N1bWVudGVkIG9yIGZpeGVkIGlu CnRoZSBmdXR1cmUuCgpDQgoKT24gMTAvMTcvMDcsIFN1biBZaS1NaW5nIDxkb2xtZW5zQGdtYWls LmNvbT4gd3JvdGU6Cj4gSGkgZ3V5cywKPiBJIHRyeSB0byBjb21waWxlIGxpYmV2ZW50LTEuM2Ug b24gbXkgZGViaWFuIGV0Y2ggYm94LCBhbmQgZ290IGFuIGVycm9yCj4gbWVzc2FnZSB3aGljaCBp cyAiZXZlbnQuaDoyMTQ6IGVycm9yOiBleHBlY3RlZAo+IHNwZWNpZmllci1xdWFsaWZpZXItbGlz dCBiZWZvcmUgJ3VfY2hhciciLgo+IElzIGl0IGEgYnVnIG9yIGRpZCBJIGRvIHNvbWV0aGluZyB3 cm9uZy4KPiBidHcsIGlmIGkgcHV0IGFuIHN0YXRlbWVudCAiIHR5cGVkZWYgdW5zaWduZWQgY2hh ciB1X2NoYXI7IiBiZWZvcmUKPiBpbmNsdWRlIGV2ZW50LmgsIHRoZSBjb21waWxlIGdvZXMgc21v b3RobHkuCj4KPiAjaW5jbHVkZSA8c3RkaW8uaD4KPiAvLyB0eXBlZGVmIHVuc2lnbmVkIGNoYXIg dV9jaGFyOwo+ICNpbmNsdWRlIDxldmVudC5oPgo+Cj4gaW50IG1haW4oKQo+IHsKPiAgICAgICAg cmV0dXJuIDA7Cj4gfQo+IC0tCj4gU2luY2VyZWx5LAo+Cj4gy+/Su8P5IFNpbW9uIFN1bgo+IC0t Cj4gQmUgYSBtYW4gd2l0aCBzaW1wbGUgaW50ZXJmYWNlLgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMaWJldmVudC11c2VycyBtYWlsaW5nIGxp c3QKPiBMaWJldmVudC11c2Vyc0Btb25rZXkub3JnCj4gaHR0cDovL21vbmtleS5vcmcvbWFpbG1h bi9saXN0aW5mby9saWJldmVudC11c2Vycwo+Cj4K From dolmens at gmail.com Wed Oct 17 05:30:27 2007 From: dolmens at gmail.com (Sun Yi-Ming) Date: Wed Oct 17 05:30:31 2007 Subject: [Libevent-users] event.c:166 clock_gettime undefined reference Message-ID: <6893328f0710170230v46e6eddcq22d40b89515b73f8@mail.gmail.com> Hi guys, when I compile my simple test file which just has an event_init() against the static library libevent.a, I got an error message which said that "event.c:166 clock_gettime undefined reference"(something like that, I uses a non-english locale debain.). But if I compile against the shared library -levent, all is ok. what happened? gcc (GCC) 4.1.2 Debian 4.1.1-21 -- Sincerely, ??? Simon Sun -- Be a man with simple interface. From yoonghm at gmail.com Wed Oct 17 10:24:13 2007 From: yoonghm at gmail.com (Hor Meng Yoong) Date: Wed Oct 17 10:25:06 2007 Subject: [Libevent-users] event.c:166 clock_gettime undefined reference In-Reply-To: <6893328f0710170230v46e6eddcq22d40b89515b73f8@mail.gmail.com> References: <6893328f0710170230v46e6eddcq22d40b89515b73f8@mail.gmail.com> Message-ID: <27726d480710170724k455aebb9xa4276e2103012f83@mail.gmail.com> Hi: clock_gettime needs to use librt library. Include with -lrt. When you have compiled it successfully using -levent, check with ldd to see which library it links to. Regards Hor Meng On 10/17/07, Sun Yi-Ming wrote: > > Hi guys, when I compile my simple test file which just has an > event_init() against the static library libevent.a, I got an error > message which said that "event.c:166 clock_gettime undefined > reference"(something like that, I uses a non-english locale debain.). > But if I compile against the shared library -levent, all is ok. what > happened? > > gcc (GCC) 4.1.2 > Debian 4.1.1-21 > -- > Sincerely, > > ËïÒ»Ãù Simon Sun > -- > Be a man with simple interface. > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071017/23e55bf8/attachment.htm From nickm at freehaven.net Thu Oct 18 13:49:49 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Thu Oct 18 13:50:11 2007 Subject: [Libevent-users] [PATCH] libevent/event.3: small cleanup and additional notes In-Reply-To: <20070926121623.GA988@ns1.anodized.com> References: <20070926121623.GA988@ns1.anodized.com> Message-ID: <20071018174949.GI6199@totoro.wangafu.net> On Wed, Sep 26, 2007 at 05:16:23AM -0700, Christopher Layne wrote: > It's really difficult to have a diff explain manpage changes due to > the nature of ROFF markup, etc. What I like to do in this situation is to compare the roff'd output in order to see what the inputs are. (Patch applied in trunk.) 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/20071018/9ab14b5f/attachment.bin From provos at citi.umich.edu Sat Oct 20 13:22:27 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat Oct 20 13:22:37 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> Message-ID: <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> After talking with Nick, I think the solution that makes the most sense is to build three different libraries: - libevent-core which contains only the event loop - libevent-extras which contains DNS, HTTP, etc. - libevent which contains everything for backwards compatibility That should make everyone happy. Niels. On 10/2/07, Chris Brody-GMail wrote: > On 10/2/07, Nick Mathewson wrote: > > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > > [...] > > > libcurl has developed a good API for its integration with libevent. > > > libcurl project also maintains and develops a very good asynchronous DNS > > > client library, called c-ares (a clone of ares). > > > > > > Could it be a better path to concentrate the community efforts on > > > integration of c-ares and libcurl with libevent and to assist better > > > to applications? > > > > I would love somebody to get c-ares working right with libevent. I > > don't think this is a matter of "concentrating the community efforts", > > however: I think it's a matter of somebody stepping up to contribute > > the right patch to c-ares. > [...] > I am happy to take a look in my free time, despite a lack of > experience with libcurl & c-ares. I hope the HTTP & DNS parts of > libevent can be officially built separately, regardless about where > the source code is kept. > > Due to a lack of "official" RPM, my company is building libevent > ourselves, so I would like to try Christopher's patches to Makefile.am > & configure.in internally and report the results. > > I would like to suggest another idea, to automatically build both a > "full" libevent library and a set of separated libevent parts, until > the next major release. > > Chris > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From nickm at freehaven.net Sat Oct 20 19:15:53 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Sat Oct 20 19:16:02 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> Message-ID: <20071020231553.GN6192@totoro.wangafu.net> On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote: > After talking with Nick, I think the solution that makes the most > sense is to build three different libraries: > > - libevent-core which contains only the event loop > - libevent-extras which contains DNS, HTTP, etc. > - libevent which contains everything for backwards compatibility > > That should make everyone happy. Okay! I'll do this in trunk in the next couple of days, assuming that nobody objects. Another issue: We're apparently using the --revision and --version arguments to libtool wrong. Our use of --revision means that binaries built against one version of libevent need to be rebuilt to use the next. Our current non-use f --version-info means that once we fix the --revision problem, we'll give linkers the wrong idea about which versions of libevent are which. What we need to do in order to use --version-info correctly is described here: http://sourceware.org/autobook/autobook/autobook_91.html Is this something that we're willing to do? If I understand the documentation correctly, then practice, we'd have to keep 3 numbers: "Current", "Revision", and "Age". We'd need to note, whenever we do a new release: whether it adds new interfaces, and whether it breaks binary compatibility, and then, by cases: if (the interface changed) { if (binary compatibility isn't broken) increment "age"; Increment "current", set "revision" to 0. } else { increment "revision"; } It's a little more bookkeeping, but I believe it would make us play better with linkers and applications. For more background, see the thread "Question: Library Naming." 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/20071020/a3d28094/attachment.bin From chris.brody at gmail.com Sun Oct 21 08:00:38 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Sun Oct 21 08:00:49 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <20071020231553.GN6192@totoro.wangafu.net> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> <20071020231553.GN6192@totoro.wangafu.net> Message-ID: <7365f28e0710210500u440a96aeoe938101b89a69045@mail.gmail.com> On 10/21/07, Nick Mathewson wrote: > On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote: > > After talking with Nick, I think the solution that makes the most > > sense is to build three different libraries: > > > > - libevent-core which contains only the event loop > > - libevent-extras which contains DNS, HTTP, etc. > > - libevent which contains everything for backwards compatibility > > > > That should make everyone happy. > > Okay! I'll do this in trunk in the next couple of days, assuming that > nobody objects. Thank you guys for the attention to the issue. Small questions: 1. would the evbuffer & bufferevents still be part of the libevent-core, or something else? I am working on a C++ interface for this part. 2. Could we give "extras" a slightly sexier name such as WWW or web-server? I do find this to be a valuable part as well, and I am planning to work on a C++ interface for the HTTP server part in the future. > Another issue: We're apparently using the --revision and --version > arguments to libtool wrong. Our use of --revision means that binaries > built against one version of libevent need to be rebuilt to use the > next. Our current non-use f --version-info means that once we fix the > --revision problem, we'll give linkers the wrong idea about which > versions of libevent are which. It seems to me, that this was the equivalent of starting with 0:0:0. If I read the page right, we could use something like "1:0:1", which indicates that we have a "new" interface, but we remain backward compatible with the first version. From mail2arthur at gmail.com Mon Oct 22 13:34:50 2007 From: mail2arthur at gmail.com (arthur) Date: Mon Oct 22 13:35:07 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for--disable-dns, --disable-http, and --disable-bevents References: <676940.1059.qm@web51901.mail.re2.yahoo.com><7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com><20071002162029.GE3927@totoro.wangafu.net><7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com><850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com><20071020231553.GN6192@totoro.wangafu.net> <7365f28e0710210500u440a96aeoe938101b89a69045@mail.gmail.com> Message-ID: <001301c814d1$e13b2810$9b080f0a@usr.ingenico.loc> To KISS, do you guys think libevent can use a regular makefile (maybe multiple makefile.platform) instead automake. Just a thought from a Linux newbie developer who doesn't have autoconfig installed in his box and mostly important, only understand makefile. ;-) Thanks guys. Arthur ----- Original Message ----- From: "Chris Brody-GMail" To: "Nick Mathewson" ; "Niels Provos" Cc: Sent: Sunday, October 21, 2007 8:00 AM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for--disable-dns, --disable-http, and --disable-bevents > On 10/21/07, Nick Mathewson wrote: > > On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote: > > > After talking with Nick, I think the solution that makes the most > > > sense is to build three different libraries: > > > > > > - libevent-core which contains only the event loop > > > - libevent-extras which contains DNS, HTTP, etc. > > > - libevent which contains everything for backwards compatibility > > > > > > That should make everyone happy. > > > > Okay! I'll do this in trunk in the next couple of days, assuming that > > nobody objects. > Thank you guys for the attention to the issue. Small questions: 1. > would the evbuffer & bufferevents still be part of the libevent-core, > or something else? I am working on a C++ interface for this part. > > 2. Could we give "extras" a slightly sexier name such as WWW or > web-server? I do find this to be a valuable part as well, and I am > planning to work on a C++ interface for the HTTP server part in the > future. > > > Another issue: We're apparently using the --revision and --version > > arguments to libtool wrong. Our use of --revision means that binaries > > built against one version of libevent need to be rebuilt to use the > > next. Our current non-use f --version-info means that once we fix the > > --revision problem, we'll give linkers the wrong idea about which > > versions of libevent are which. > It seems to me, that this was the equivalent of starting with 0:0:0. > If I read the page right, we could use something like "1:0:1", which > indicates that we have a "new" interface, but we remain backward > compatible with the first version. > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From nickm at freehaven.net Mon Oct 22 19:53:44 2007 From: nickm at freehaven.net (Nick Mathewson) Date: Mon Oct 22 19:54:03 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <7365f28e0710210500u440a96aeoe938101b89a69045@mail.gmail.com> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> <20071020231553.GN6192@totoro.wangafu.net> <7365f28e0710210500u440a96aeoe938101b89a69045@mail.gmail.com> Message-ID: <20071022235344.GL6199@totoro.wangafu.net> On Sun, Oct 21, 2007 at 02:00:38PM +0200, Chris Brody-GMail wrote: [...] > Thank you guys for the attention to the issue. Small questions: 1. > would the evbuffer & bufferevents still be part of the libevent-core, > or something else? I am working on a C++ interface for this part. I'm pretty sure that evbuffer and friends should stay in event-core, for two reasons: * Unlike HTTP, RPC, and DNS, they're pretty protocol-neutral. * Like event_base, they can be optimized on different platforms in different ways. (Windows, for instance, is begging for an IOCP implementation of bufferevents. I've got one from a student that I want to merge into the next major revision or the one after that, time permitting.) > 2. Could we give "extras" a slightly sexier name such as WWW or > web-server? I do find this to be a valuable part as well, and I am > planning to work on a C++ interface for the HTTP server part in the > future. It's not www only: it's http, dns, and rpc. In the future, it might grow. I'm going to go with the name Niels gave, since it lets me make the changes sooner rather than later. :) 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/20071022/402a0d09/attachment.bin From chris.brody at gmail.com Tue Oct 23 06:17:02 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Tue Oct 23 06:17:06 2007 Subject: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents In-Reply-To: <20071022235344.GL6199@totoro.wangafu.net> References: <676940.1059.qm@web51901.mail.re2.yahoo.com> <7e63f56c0710020035x6bc09eafo442ebafce2c1d831@mail.gmail.com> <20071002162029.GE3927@totoro.wangafu.net> <7365f28e0710021046t63e6ec66o5eb9fe5997a7005d@mail.gmail.com> <850f7cbe0710201022o30d302d8u13fa0e20f42aa6eb@mail.gmail.com> <20071020231553.GN6192@totoro.wangafu.net> <7365f28e0710210500u440a96aeoe938101b89a69045@mail.gmail.com> <20071022235344.GL6199@totoro.wangafu.net> Message-ID: <7365f28e0710230317h4d746905r27918f84266d3cff@mail.gmail.com> On 10/23/07, Nick Mathewson wrote: > On Sun, Oct 21, 2007 at 02:00:38PM +0200, Chris Brody-GMail wrote: > [...] > > Thank you guys for the attention to the issue. Small questions: 1. > > would the evbuffer & bufferevents still be part of the libevent-core, > > or something else? I am working on a C++ interface for this part. > > I'm pretty sure that evbuffer and friends should stay in event-core, [...] Good-that's what I was hoping! > It's not www only: it's http, dns, and rpc. In the future, it might > grow. Right ... I believe the original patch had also made a cleaner separation of these parts for the regression tests. Can this fix be considered as well? Thanks again, CB From chris.brody at gmail.com Tue Oct 23 06:22:26 2007 From: chris.brody at gmail.com (Chris Brody-GMail) Date: Tue Oct 23 06:22:31 2007 Subject: [Libevent-users] libevent and C++ In-Reply-To: <20071020044340.GB19086@homero.springfield.home> References: <7365f28e0709270904l7161aab8ma3cec8a048a1329@mail.gmail.com> <20071020044340.GB19086@homero.springfield.home> Message-ID: <7365f28e0710230322x11a061e9ua8b0e683417f3240@mail.gmail.com> Thanks for the update! I would also like to add an extra post that I have a project to run libevent and eventxx in the CINT C/C++ interpreter: http://code.google.com/p/event-hpp/ Chris Brody On 10/20/07, Leandro Lucarella wrote: > I just wanted you to know that eventxx home page is back up: > > http://www.llucax.com.ar/~luca/eventxx/ > > I'm sorry for the *HUGE* delay =( > > -- > Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ > .------------------------------------------------------------------------, > \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / > '--------------------------------------------------------------------' > Que el viento y la lluvia sean dos hermanos y corran furiosos por los > terraplenes de V?ctor Heredia. > -- Ricardo Vaporeso. Lan?s, 1912. > From Trond.Norbye at Sun.COM Thu Oct 25 03:44:15 2007 From: Trond.Norbye at Sun.COM (Trond Norbye) Date: Thu Oct 25 03:44:49 2007 Subject: [Libevent-users] [PATCH] Fix problems in the event port implementation for Solaris Message-ID: <4720494F.3000905@sun.com> This patch fix the following problems: * port_disassociate was sometimes called on events not associated in the event port resulting in bogus error messages being printed out * Use event_warn instead of perror * Modified the implementation of the ed_pending array to contain the index of the entry that needs to be reassociated instead of a pointer to the element (so we don't need to relocate all of the pointers when the array is relocated) Trond Norbye -------------- next part -------------- A non-text attachment was scrubbed... Name: evport.c.patch Type: text/x-patch Size: 6378 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20071025/4243f3f4/evport.c-0001.bin From daniminas at gmail.com Thu Oct 25 20:06:41 2007 From: daniminas at gmail.com (Daniel Morales) Date: Thu Oct 25 20:06:58 2007 Subject: [Libevent-users] event_dispatch and event_loop Message-ID: Hi all.. first time here I've to modify an application, right now it's using event_dispatch () and event_loopexit (). Now, I've to do the task in a thread, and I've to control the thread. The basic thread function has to be something like: while (events_running) { /* Events paused */ if (events_paused) continue; event_loop (EVLOOP_NONBLOCK); } My question is if event_dispatch () and the new code with event_loop will work in the same way. Thanks for any reply, and sorry my english :) -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071025/2c922fbe/attachment.htm From pfisher at alertlogic.net Tue Oct 30 09:24:52 2007 From: pfisher at alertlogic.net (Paul Fisher) Date: Tue Oct 30 09:25:38 2007 Subject: [Libevent-users] [PATCH] Initialize current_base only once Message-ID: <307EFBA19B7B8D41A3E823644410291F30270A@exchange01.alertlogic.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: 001_first_current_base.patch Type: text/x-patch Size: 352 bytes Desc: 001_first_current_base.patch Url : http://monkeymail.org/archives/libevent-users/attachments/20071030/d237f0f6/001_first_current_base.bin From mail2arthur at gmail.com Tue Oct 30 09:47:16 2007 From: mail2arthur at gmail.com (arthur) Date: Tue Oct 30 09:47:29 2007 Subject: [Libevent-users] semaphore event References: <7365f28e0709270904l7161aab8ma3cec8a048a1329@mail.gmail.com><20071020044340.GB19086@homero.springfield.home> <7365f28e0710230322x11a061e9ua8b0e683417f3240@mail.gmail.com> Message-ID: <000601c81afb$660c1340$9b080f0a@usr.ingenico.loc> Hi All, I am working on simple socket proxy/filter. To overcome the limitation of fd's per process, the main creates a semaphore, and forks after create listen socket, then the one which gets semaphore will accept. When the active process reaches this max connections, it unlocks the semaphore and stops accepting so anther process will start to work. My question is regarding reactive the first process, for now it checks (can't wait since we need keep event_dispatch running) the semaphore whenever closing a connection but I feel the code a little ugly (keep checking in an event driven app). Can I get a libevent event for semaphore notification, like the how the signal works. Thanks in advance. Cheers, Arthur From pfisher at alertlogic.net Tue Oct 30 11:30:26 2007 From: pfisher at alertlogic.net (Paul Fisher) Date: Tue Oct 30 11:29:26 2007 Subject: [Libevent-users] [PATCH] TAILQ_ENTRY missing in evhttp.h on linux Message-ID: <307EFBA19B7B8D41A3E823644410291F30270D@exchange01.alertlogic.net> In using the latest 1.3e on linux, evhttp.h fails to compile because of a missing definition of TAILQ_ENTRY in evhttp.h. This is due to the fact that the workaround in event.h is #define'd and #undef'd within event.h and not available to evhttp.h when defining "struct evhttp_request". This patch obviously fixes it: --- libevent-1.3e/evhttp.h 2007-08-25 13:49:22.000000000 -0500 +++ libevent-1.3e.002/evhttp.h 2007-10-29 22:32:07.000000000 -0500 @@ -108,7 +108,14 @@ * reasonable accessors. */ struct evhttp_request { +#if defined(TAILQ_ENTRY) TAILQ_ENTRY(evhttp_request) next; +#else +struct { \ + struct type *tqe_next; /* next element */ \ + struct type **tqe_prev; /* address of previous next element */ \ +} next; +#endif /* the connection object that this request belongs to */ struct evhttp_connection *evcon; ... but it would be nice if this was coordinated with the definition in event.h, possibly by simply not #undef'ing it from event.h. Anyway, if there is a preference on how to fix this, I'd be glad to regenerate the patch. -- paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20071030/eb23f953/attachment.htm