Hi!
On tuesday, I sent mail about various problems with libevent and its
current API as well as implementation. Unfortunately, the mail has not yet
shown up, but fortunately, it has been superseded by this one :)
In that mail, I announced that I will work on the problems I encountered
in libevent
On Sat, Nov 03, 2007 at 09:15:07PM +0100, Marc Lehmann wrote:
> In that mail, I announced that I will work on the problems I encountered
> in libevent (many of which have been reported and discusssed earlier on
> this list). After analyzing libevent I decided that it wasn't fixable
> except by rew
during integration of libev into libevent, I found that the test/* files
include the *installed* header files instead of the ones from the package.
this doesn't work if there are any structure changes (obviously the structure
change in this case was going to libev).
fixing the #include statement
Hi Marc,
I appreciate your insights, but your message has nothing to do with
libevent. The make files in libevent use the -I option to provide the
path to the header files.
I also noticed that you seem to have found several bugs in libevent.
It would be nice if you could send patches for them.
The attached patch allows an evhttp server to properly operate on an
alternative event_base that is set via a new interface evhttp_base_start(),
which is also added by this patch. Basically this makes the http.c
implementation apply the event_base present in the struct evhttp instance
associate
Try
#include
before including evhttp.h
Niels.
On 10/30/07, Paul Fisher <[EMAIL PROTECTED]> wrote:
>
>
>
> 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 #def
Hi Paul,
thank you very much for your patch. Unfortunately, something very
similar is already present in trunk:
/** Create a new HTTP server
*
* @param base (optional) the event base to receive the HTTP events
* @return a pointer to a newly initialized evhttp server structure
*/
struct evhtt
On Sat, Nov 03, 2007 at 04:56:07PM -0700, Niels Provos wrote:
> Try
>
> #include
>
> before including evhttp.h
>
> Niels.
Why is this a usercode issue? Shouldn't evhttp.h be more interested in
handling it's dependencies than non-event parent code? It's similar to the
being a usercode, but eve
Then why does event.h go to the trouble of #ifndef TAILQ_ENTRY to handle the
same issue? And why not have event.h include the file directly?
--
paul
-Original Message-
From: [EMAIL PROTECTED] on behalf of Niels Provos
Sent: Sat 11/3/2007 6:56 PM
To: Paul Fisher
Cc: libevent-users@mon
On Sat, Nov 03, 2007 at 05:18:51PM -0700, Christopher Layne <[EMAIL PROTECTED]>
wrote:
> On Sat, Nov 03, 2007 at 04:56:07PM -0700, Niels Provos wrote:
> > Try
> >
> > #include
> >
> > before including evhttp.h
> >
> > Niels.
>
> Why is this a usercode issue? Shouldn't evhttp.h be more interes
While debugging a problem of http.c with libev, I found this code
in evhttp_write_buffer:
if (event_pending(&evcon->ev, EV_WRITE|EV_TIMEOUT, NULL))
event_del(&evcon->ev);
event_set(&evcon->ev, evcon->fd, EV_WRITE, evhttp_write, evcon);
evhttp_add_event(&evc
Hi Marc,
I think the documentation is very clear on this:
The function event_set() prepares the event structure ev to be used in
future calls to event_add() and event_del(). The event will be
prepared to call the function specified by the fn argument with an int
argument indicating the file desc
On 11/3/07, Christopher Layne <[EMAIL PROTECTED]> wrote:
> Why is this a usercode issue? Shouldn't evhttp.h be more interested in
> handling it's dependencies than non-event parent code? It's similar to the
> being a usercode, but event.h dependency as well. I mean why
> not make the parent code j
On Sat, Nov 03, 2007 at 05:40:50PM -0700, Niels Provos <[EMAIL PROTECTED]>
wrote:
> I think the documentation is very clear on this:
I read that part, but the documentation doesn't mention anything about wether
one can pass in uninitalised memory (as I explained in my mail).
Did you read it?
>
On Sun, Nov 04, 2007 at 01:57:31AM +0100, Marc Lehmann <[EMAIL PROTECTED]>
wrote:
> > I find your somewhat discourteous insinuation of bugs distracting.
>
> 1. I reported a number of bugs in libevent so far. I am not insinuating,
>but reporting bugs, to improve libevent.
I wanted to mention
On Sat, Nov 03, 2007 at 05:53:42PM -0700, Niels Provos wrote:
> Well, Rob Pike has many great insights. He also does not like
> conditional compilation. However, you are right, evhttp.h could
> resolve the dependency on queue.h internally. I will look into it.
Agreed, Rob Pike is true blue - an
On Sun, Nov 04, 2007 at 02:00:15AM +0100, Marc Lehmann <[EMAIL PROTECTED]>
wrote:
> On Sun, Nov 04, 2007 at 01:57:31AM +0100, Marc Lehmann <[EMAIL PROTECTED]>
> wrote:
> > > I find your somewhat discourteous insinuation of bugs distracting.
> >
> > 1. I reported a number of bugs in libevent so f
On Sat, Nov 03, 2007 at 04:18:19PM -0700, Niels Provos wrote:
> Hi Marc,
>
> I appreciate your insights, but your message has nothing to do with
> libevent. The make files in libevent use the -I option to provide the
> path to the header files.
I just tried to test this out, as follows. I built
On Sat, Nov 03, 2007 at 03:45:39PM -0700, William Ahern <[EMAIL PROTECTED]>
wrote:
> A good itch, indeed.
I am currently working on integrating all modules from libevent, so it
becomes a full libevent replacement (and it already runs all of the
testsuite that doesn't require access to internals).
On Sat, Nov 03, 2007 at 04:18:19PM -0700, Niels Provos <[EMAIL PROTECTED]>
wrote:
> I appreciate your insights, but your message has nothing to do with
> libevent. The make files in libevent use the -I option to provide the
> path to the header files.
Well, since you thre documentation at me bef
On Sun, Nov 04, 2007 at 03:02:02AM +0100, Marc Lehmann wrote:
> On Sat, Nov 03, 2007 at 04:18:19PM -0700, Niels Provos <[EMAIL PROTECTED]>
> wrote:
> > I appreciate your insights, but your message has nothing to do with
> > libevent. The make files in libevent use the -I option to provide the
> >
21 matches
Mail list logo
