Re: Re: [Libevent-users] HTTP proxy based on evhttp layer?
> https://baus.net/switchflow Sorry make that: http://baus.net/switchflow ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: Re: [Libevent-users] HTTP proxy based on evhttp layer?
> Hi£¬Elliot > > Niels announces here > > http://monkeymail.org/archives/libevent-users/2007-February/000547.html > > best regards£¬ > stephen > > > === 2007-05-11 00:36:27 ÄúÔÚÀ´ÐÅÖÐдµÀ£º=== > James Yonan wrote: >>> I'd like to know if anyone has developed a simple HTTP proxy based on >>> the evhttp layer? I am probably going to move away from libevent to boost::asio, but if anybody is interested in a C++ reverse proxy based on libevent: https://baus.net/switchflow It's under the Boost license which is similar to MIT and BSD. Thanks, Chris ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent 1.2
>> The slickest implementation I've seen that works with *nix non-blocking >> I/O and Windows IOCP is boost ASIO http://asio.sourceforge.net/. >> Instead >> of modeling reactive behavior with IOCP, it mimics proactive behavior on >> *nix. It works out surprisingly well. > > I'm privy to my own [C] library which does this and more. Still, I don't > think this necessarily belongs in libevent. I'm not recommending that this should be in libevent, but if you are looking for something that abstracts out both IOCP and non-blocking sockets, ASIO is a good place to start. http://baus.net/ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent 1.2
> Has there been much interest in an IOCP port for libevent? I would > certainly be interested. > I even started working on a rough port, but as mentioned IOCP is proactive > rather than reactive, > (ie you tell it how much to read/send and the event tells you that) and it > got rather awkward pretty quickly. The slickest implementation I've seen that works with *nix non-blocking I/O and Windows IOCP is boost ASIO http://asio.sourceforge.net/. Instead of modeling reactive behavior with IOCP, it mimics proactive behavior on *nix. It works out surprisingly well. Christopher http://baus.net/ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: http Re: [Libevent-users] Q about 1.2 release
> 2. If anybody wants to play with / improve my "http > on top of libevent implementation" - pelase email me > offlist - the code should go opensource by the middle > of September. > > Rgds.Paul. > I'll race you :) I also have a C++ HTTP implementation that I have worked on for a couple years. I really need to open source it, but I've gotten busy in the last 6 months. Niels announcement makes me want to kick my work back into high gear. I have keep-alive, pipelines, per event tokenizing, and client and server support. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] guidance on conversion from EV_READ events to bufferevent_read() in libevent
> I've written a fairly extensive set of libraries and applications that are > based on libevent. > > Because of the way I've implemented the event based solution to handling > an internal message protocol we send over a socket, I find my application > using 100% of the CPU dealing with data coming in over the various > sockets. > > Currently I've implemented this by setting an EV_READ event for a new file > descriptor. Because of the way I'm handling our protocol when I get a > read event on the fd, I only read a portion of the data that may be > available to be read, and then reschedule the event, (thinking I would > minimize starvation of other events) > > but since there is still data to read the is readable fires again(?) and > as a result given the 100's of connections and 50 msg/sec data rates I > have, the process chews through CPU dealing with the constant state of > isReadable. > Don't reschedule the event until read() returns EAGAIN. If I need another event (eg. write) I just maintain the readability of the fd in a application layer flag. Otherwise you end up with the live lock situation you describe. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent for regular file descriptors
> > As said, we got bitten by the static FD_SETSIZE as ACE uses it (it does > *not* malloc the fd_sets, so we can only handle at most 1024 fds). And > ACE uses select which doesn't scale well, while libevent is able to > leverage scalable interfaces such as epoll or kqueue. The latest version has support for epoll and kqueue. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent for regular file descriptors
For our model we didn't need it. Either we fork, so only the main process (single-threaded) uses libevent, or we make worker threads and only the main thread uses libevent. The workers are synchronized using mutexes, a semaphore (main -> worker) and a pipe (worker -> main) only. The only problem here is that you are doing a frivolous lock if the API is thread safe (such as sys_epoll). Considering that the app is probably I/O bound anyway this might not matter. I so suspect the problems of switching to ACE would be worse than continuing down this route. Christopher ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent for regular file descriptors
> In fact that's what I do too, after handling I/O in the main program > didn't work out well enough. Not exactly indeed. Instead we fork/exec off > some number of helper processes (even with a little separate I/O helper > binary) and talk a little protocol to them over unix domain sockets. > They're fast enough so we don't do any shared memory hacks or similar. This is one reason why I think it would be nice to reconsider the thread safety of libevent. There are race conditions with multiple threads adding events to a poller. While I think it will work with epoll in most situations, libevent doesn't make this guarantee. I keep going back and forth between libevent and much heavier solutions like Doug Schmidt's ACE because of issues like this. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
[Libevent-users] (no subject)
> You can use inotify to give you an event when a file changes. > This is an orthogonal issue. inotify is used to monitor a file for modifications, not if it is ready to read or write w/out blocking. Disk I/O options could block if the disk cache is empty and disk is seeking for instance. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent for regular file descriptors
> Linux doesn't support non-blocking I/O on files. If you don't require > high throughput to disk your best bet is to use worker threads. This is > basically how squid handle's its disk cache. Opps, that should read if you DO require high disk throughput. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent for regular file descriptors
> Thank you, Its very interesting , because I'm using 2.6.5 kernel which > does supports epoll , but every time I tried call a epoll_ctl with an > ADD operation on the regular file , I get back a NOPERM errro back, so I > was wondering if anybody succeeded before ( google not in much help :() Linux doesn't support non-blocking I/O on files. If you don't require high throughput to disk your best bet is to use worker threads. This is basically how squid handle's its disk cache. If you are doing light disk writes your application might be able to get away with blocking files because writes to the disk cache are basically non-blocking. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent and GPL
> If I look at the file poll.c, for example, I see the *3*-clause BSD > license, which has dropped exactly the one clause from the original > 4-clause BSD license which was probably incompatible with the GPL > (the so-called advertising clause). Opps. I thought advertising clause was still in there. Ok cool. I'm going to try to get my code out in the next couple weeks. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
[Libevent-users] libevent and GPL
Niels, I want to release an HTTP library that is based on libevent under GPL, but it is stated in many places that the original BSD license that you use is incompatible with the GPL. I just want to confirm that this is your intention, and if not ask if you would consider the revised BSD or MIT licenses. Otherwise, I might have to consider porting to another event distribution library, and given the time I have invested with libevent, I really don't want to do that. Christopher ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
