Re: [Libevent-users] libevent 1.2

[Jason Ish]

On Mon, Oct 16, 2006 at 10:18:28PM -0700, Niels Provos wrote:
> Hi everyone,
> 
> libevent 1.2 was released yesterday.  There are some major feature 
> improvements:
> 
>  - Support for non-blocking DNS resolution
> - Support for lightweight HTTP clients and servers
> - Support for Sun's Event Ports

Are there future plans to add more utilities that layer on top of
libevent?  I do see the utility in lightweight http support (friendly
debug interface to a daemon and such), but I've also appreciated
libevent for being small and providing me an abstraction to the
various underlying mechanisms.  For example, are we going to see more
framework type utilities in libevent proper, or leave them as addons.

I ran across at least one criticism of libevent gaining too much other
than pure event library:
http://varnish.projects.linpro.no/wiki/EventLibrary

For example, I as well as others have evolved code around libevent for
dealing with threads and SSL, are we going to see support code
eventually rolled in or will libevent stick primarily to be an event
mechanism?

Thanks for the great work!

-- Jason
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Robert Iakobashvili]

Hi Gordon,

On 10/18/06, Gordon Scott <[EMAIL PROTECTED]> wrote:


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.

It might be worth finding some way to wrap the IOCP structures in a
module/class that behaves a little more like standard sockets so it would be
easier to integrate.



Y might wish to look at ACE-library and its Proactor pattern, wish
known to be very robust on windows. This is C++, however.
http://www.cs.wustl.edu/~schmidt/ACE.html

--
Sincerely,
--
Robert Iakobashvili, coroberti at gmail dot com
Navigare necesse est, vivere non est necesse.
--
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[William Ahern]

On Wed, Oct 18, 2006 at 12:21:17AM -, Christopher Baus wrote:
> 
> >> 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.
> 

I wouldn't write a project in C++ if you paid me a million dollars. ;)

But, I understand what you mean, considering you're not just speaking to me.

http://25thandclement.com/~william/projects/libevnet.html
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Christopher Baus]

>> 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

[William Ahern]

On Tue, Oct 17, 2006 at 11:33:30PM -, Christopher Baus wrote:
> > 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.

I'm privy to my own [C] library which does this and more. Still, I don't
think this necessarily belongs in libevent.

libevent is popular because it does cross-platform event _polling_ very
well, in a clean and simple interface.

Integrating compound (higher-level) asynchronous actions like this is still
a very fluid area. Take the recent DNS support in 1.2. It's probably going
to follow the same tired path that c-ares, ADNS and UDNS have... slow and
abortive patches for IPv6, SRV, CNAME, et al (granted UDNS has probably done
the best out of all of them).

libevent fills in its niche almost perfectly. If it starts to spill out all
over the place things will only get messier; libevent originally made things
cleaner.

Maybe it's inevitable... I suppose that's how fluid areas become well trodden
ground.

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Christopher Baus]

> 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: [Libevent-users] libevent 1.2

[Gordon Scott]

>>Neato! Seems you've subsumed most OS event waiting interfaces.>>Does that include win32 IOCPs (io completion ports) yet?>>If not, they're definitely worth a look. However, they're not very
>>"selecty", in that they scale well and they tell you when something>>has actually happened instead of when something might happen without>>blocking, maybe. I don't know how well that would fit in with libevt.
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.
It might be worth finding some way to wrap the IOCP structures in a module/class that behaves a little more like standard sockets so it would be easier to integrate. 
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Scott Lamb]

On Oct 17, 2006, at 11:08 AM, Rhythmic Fistman wrote:

That's funny, there doesn't seem to be a self-pipe-trick
implementation in lib-evt... how do you get by without it?


There is, although it uses a socketpair() instead of a pipe().

--
Scott Lamb 


___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Jarrod Roberson]

On 10/17/06, Scott Lamb <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 12:19 PM, Rhythmic Fistman wrote:> On 10/17/06, Scott Lamb <[EMAIL PROTECTED]> wrote:>> On Oct 17, 2006, at 11:08 AM, Rhythmic Fistman wrote:
>> > That's funny, there doesn't seem to be a self-pipe-trick>> > implementation in lib-evt... how do you get by without it? There is, although it uses a socketpair() instead of a pipe().
>> Ah, I was grepping "trick". It looks like it's used internally in> the signal style implementations - so how does a multithreaded> app get thread_dispatch to return when it's time to exit?
libevent doesn't have any interthread communication. But you canlayer stuff on top of it - look through the archives for a coupleposts by Andrew Danforth.Message-ID:<
[EMAIL PROTECTED]>Date: Thu, 5 Oct 2006 21:42:35 -0400From: "Andrew Danforth" <[EMAIL PROTECTED]>References: <
[EMAIL PROTECTED]>Subject: [Libevent-users] Re: Passing data between event loops inmultithreaded apps
and his code at I've been thinking that a fancier threading system might performbetter, but I still haven't found the time to write and benchmark
different approaches.--Scott Lamb ___Libevent-users mailing list
Libevent-users@monkey.orghttp://monkey.org/mailman/listinfo/libevent-users
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Scott Lamb]

On Oct 17, 2006, at 12:19 PM, Rhythmic Fistman wrote:

On 10/17/06, Scott Lamb <[EMAIL PROTECTED]> wrote:

On Oct 17, 2006, at 11:08 AM, Rhythmic Fistman wrote:
> That's funny, there doesn't seem to be a self-pipe-trick
> implementation in lib-evt... how do you get by without it?

There is, although it uses a socketpair() instead of a pipe().


Ah, I was grepping "trick". It looks like it's used internally in
the signal style implementations - so how does a multithreaded
app get thread_dispatch to return when it's time to exit?


libevent doesn't have any interthread communication. But you can  
layer stuff on top of it - look through the archives for a couple  
posts by Andrew Danforth.


Message-ID:  
<[EMAIL PROTECTED]>

Date: Thu, 5 Oct 2006 21:42:35 -0400
From: "Andrew Danforth" <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: [Libevent-users] Re: Passing data between event loops in
multithreaded apps

and his code at 

I've been thinking that a fancier threading system might perform  
better, but I still haven't found the time to write and benchmark  
different approaches.


--
Scott Lamb 


___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Rhythmic Fistman]

On 10/17/06, Scott Lamb <[EMAIL PROTECTED]> wrote:

On Oct 17, 2006, at 11:08 AM, Rhythmic Fistman wrote:
> That's funny, there doesn't seem to be a self-pipe-trick
> implementation in lib-evt... how do you get by without it?

There is, although it uses a socketpair() instead of a pipe().


Ah, I was grepping "trick". It looks like it's used internally in
the signal style implementations - so how does a multithreaded
app get thread_dispatch to return when it's time to exit?
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Rhythmic Fistman]

From: "Niels Provos" <[EMAIL PROTECTED]>
libevent 1.2 was released yesterday.  There are some major feature improvements:

  - Support for non-blocking DNS resolution
 - Support for lightweight HTTP clients and servers
 - Support for Sun's Event Ports


Neato! Seems you've subsumed most OS event waiting interfaces.
Does that include win32 IOCPs (io completion ports) yet?
If not, they're definitely worth a look. However, they're not very
"selecty", in that they scale well and they tell you when something
has actually happened instead of when something might happen without
blocking, maybe. I don't know how well that would fit in with libevt.

P.S. What was the story with kqueue bug workaround for osx10.4
that appeared in libevt1.1? The "bug" detection code seems to
consider the kq impl broken depending on how it reported the
error of waiting for data on an invalid file descriptor...
How did libevt come to depend on that kind of behaviour?
Do you often wait for evts on invalid file descriptors? Is it
some sort of convoluted method for waking the given select-style
interface? That's funny, there doesn't seem to be a self-pipe-trick
implementation in lib-evt... how do you get by without it?
Anyway, I've wandered off the beaten track a bit.

Toodles,
RF
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] libevent 1.2

[Richard Nyberg]

At Mon, 16 Oct 2006 22:18:28 -0700,
Niels Provos wrote:
> 
> Hi everyone,
> 
> libevent 1.2 was released yesterday.  There are some major feature
> improvements:
> 
>  - Support for non-blocking DNS resolution
>  - Support for lightweight HTTP clients and servers Support for
>  - Sun's Event Ports
> 
> There have also been several bugfixes.  I hope this works on your
> system.  If not, please send me patches to fix.  More information
> including credits at:
> 
Thanks for this! The dns and http code is just what I needed.
Here's a patch to make evdns_resolv_conf_parse return 1 if it fails
to open the file.

-Richard

--- evdns.c.orig2006-10-17 19:22:10.0 +0200
+++ evdns.c 2006-10-17 19:22:48.0 +0200
@@ -1800,7 +1800,7 @@
fd = open(filename, O_RDONLY);
if (fd < 0) {
evdns_resolv_set_defaults(flags);
-   return 0;
+   return 1;
}
 
if (fstat(fd, &st)) { err = 2; goto out1; }
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users