olla,
I dont know what the process for submitting patches here,
but this is against version 1.4.9.
This makes it easier to integrate libraries that provide their own
read/write functions (such as openssl).
Example usage would be something like:
-
static
size_t myrcb(int fd, void *buf,
On Thu, Feb 19, 2009 at 5:09 AM, jamal h...@cyberus.ca wrote:
This makes it easier to integrate libraries that provide their own
read/write functions (such as openssl).
I haven't looked at the patch, but I'm a little skeptical of a one-size-fits-all
approach to integrating things like openssl.
On Thu, 2009-02-19 at 05:35 -0800, Dan Kegel wrote:
I haven't looked at the patch,
sufficient to look at the simple example usage shown in the email
but I'm a little skeptical of a one-size-fits-all
approach to integrating things like openssl. As the openssl faq says, you
can't just call
On Thu, Feb 19, 2009 at 08:09:18AM -0500, jamal wrote:
olla,
I dont know what the process for submitting patches here,
but this is against version 1.4.9.
This makes it easier to integrate libraries that provide their own
read/write functions (such as openssl).
Hi, Jamal!
Thanks for the
Hi Nick,
On Thu, 2009-02-19 at 10:33 -0500, Nick Mathewson wrote:
Thanks for the patch, but the Libevent 2 dev series (currently calling
itself 1.4.99) handles evbuffers and bufferevents significantly
differently. (Old code still works, but the implementation is more
efficient.) We're
I hope i come out sound patronizing or putting down the good
work done in libevent.
Is libevent trying to be too many things? I love the
all-things-IO libevent provides; i guess buffer events are a natural
evolution path - but why all the DNS or HTTP stuff? whats next?
Is the end goal to become
On Thu, 2009-02-19 at 11:13 -0500, jamal wrote:
I hope i come out sound patronizing or putting down the good
work done in libevent.
Sorry: I meant quiet the opposite ;-
i.e hope i dont come out sounding patronizing.
cheers,
jamal
___
Libevent-users
On Thu, Feb 19, 2009, jamal wrote:
I hope i come out sound patronizing or putting down the good
work done in libevent.
Is libevent trying to be too many things? I love the
all-things-IO libevent provides; i guess buffer events are a natural
evolution path - but why all the DNS or HTTP
jamal wrote:
Is libevent trying to be too many things? I love the
all-things-IO libevent provides; i guess buffer events are a natural
evolution path - but why all the DNS or HTTP stuff?
The DNS and HTTP stuff is there so people don't have to constantly
re-invent those tasks themselves.
Hello all,
if with async io is meant doing native async disc / file io, then
there already is code that integrates with libevent-2.0.
Recently, Valery Kholodkov and myself did some work in this direction.
The latest version you can find in Valery's git tree right here:
On Thu, Feb 19, 2009, Nick Mathewson wrote:
If I understand correctly, Adrian, you also think that bufferevent-ish
stuff should have API-separation from the event-ish stuff (which I
believe in) and that it should go into a separate library from
libevent_core (which I don't agree with, but I
11 matches
Mail list logo