On Thu, Nov 08, 2007 at 07:59:59PM +0100, Chris Brody-GMail <[EMAIL PROTECTED]>
wrote:
> > core, which is a drop-in replacement for libevent, fixing API problems with
> > a new API while providing libevent compatibility.
> Thank you for sharing the contribution-I will try to use it both at
> work and for a personal project.
Your experiences would be very helpful no doubt, but remember it is not
production ready (although I am starting to use it everywhere myself now,
as thats the best way to make it production-ready).
> My first suggestion is to run aclocal and include some of the
> generated files in any tgz "release". The autotools installed at work
> are too old for libevent, so I have to use my personal OSX laptop to
> take this first step.
Well, I use the libevent Makefile/autoconf and "make dist" targets. If
files are missing, I wonder how libevent releases are being prepared if
they are included there.
OTOH, the files you mentioned are not needed unless you use autotools
yourself, so including them would be pointless (as they depend on the
version of autoconf/automake in use), actually even dangerous.
If you don't want to use autotools, you cna just use the configure script.
> > - select (tested on win32, linux, freebsd)
> > - poll (tested on linux, freebsd)
> > - epoll (tested on linux)
> > - kqueue (tested on freebsd (and os x where it was disabled as with
> > libevent)))
> I had tested building an "embedded" version of the library to run in a
> C++ interpreter, and had better luck with kqueue than select on OSX
> after a recent OSX update.
libevent (and libev) test for kqeue bugs in the same way (I hope). If
kqueue actually works as by that tets it would be nice to know if the
libev kqueue backend also starts working twith recent versions of osx.
> > So I wonder if it would indeed be better to make a standalone release of
> > libev without the extra http, dns parts and so on (possibly including the
> > buffer code).
> My first suggestion would be to build in separate parts. My suggestion
> would be to keep the HTTP & DNS in their own parts, and possibly a
> separate part for the evbuffer.
This would happen automatically, as I can see this being done to libevent,
and the distribution prepared by me uses all the configure etc. stuff from
libevent, so future releases of libevent which feature this separation
would easily be followed by libev "releases" with the same features.
(Not sure about evbuffer, though, which is likely counted as core part).
So if I do nothing, this separation will come in exactly the same way
as libevent implements them.
> Another idea would be to use the same event structure as the original
> libevent, so that one could dynamically the libevent-extras library to
> your new libev library without a rebuild. Maybe this would not be
> useful, but just an idea...
I am not sure what that means (mostly because I don't understand what
"event structure" means - events are handled pretty similarly to libevent
actually, the biggets change is different watcher types). If you mean
mixing libevent and libev libraries, this cannot ever work, as the
libraries are not binary-compatible (and can never be, you cnanot fit all
the libevent members AND some emulation stuff into the same structure).
> I am actually using modified versions of all the header files for my
> home project to make them work better the CINT C++ interpreter. I
> actually renamed my copy of ev.h to ev_ev.h since OSX (and a few other
> things) already have an ev.h and I wanted to avoid an include path
> headache. Is this something you would consider?
I'd like to avoid it at all costs. For embedding, I would consider another
configuration macro, along the line sof either:
#define EV_DONT_INCLUDE_EV_H 1 /* keeps ev.c and others from including ev.h
*/
#define EV_H "ev_ev.h" /* include this file instead of ev.h */
that would solve this problem when embedding. When using the library it
shouldn't be so problematic to solve the include issue differently (as its
a common problem when installing multiple versions of some library and
easy to solve).
> I wonder if we should consider starting a mail list for some of these
> libevent extensions? I recently found www.nabble.com to start a forum
> for free.
Well, unlike e.g. libevnet, its not quite an extension, but a mailinglist for
libev might become unavoidable to to social pressure and other things. I'd be
happy to provide one, too, but first I'd like to try peaceful ways of
coexisting here.
I any case, I count this as a vote to keep the libevent parts (and follow
the same road as libevent).
Thanks!
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
