> 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
> 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 o
>> 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
> 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 pr
> 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'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
>
> 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
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 prob
> 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'
> 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.
_
> 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.
___
> 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 :()
L
> 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 the
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
li
14 matches
Mail list logo
