On Thu, Nov 08, 2007 at 03:03:40PM -0500, Nick Mathewson <[EMAIL PROTECTED]>
wrote:
> Hi, Marc! I tried building Tor against libev to see how well it would
> work. There are some very cool things in your code design, but I ran
> into the following issues when I tried to run it.
Cool!
> - I got some GCC warnings when building ev.c; I've attached them.
I have removed -Wall from the default cflags for gcc, they should be gone
by now.
> - You probably want event.h to include <event_compat.h> inside angle
> brackets, not inside quotes.
Oh right, thats of course going to be a problem when embedding it. Maybe
I'll go for a #define EV_COMPAT_H thing there, too, and default to <>.
> - There's no event_active compatibility function defined. I looked
> around ev.c to try to figure out how to do it, but it looks like I
> would need to call the static function "event()" in ev.c. Instead,
> I commented out the code that used it. This breaks some Tor
> features, so I turned them off.
Oh, I assumed it wasn't a public API function, I'll include a suitable
version at once.
> - It looks like the way that fd_event() handles FD events uses an array,
> anfd, to map fd values to ev_io values. This won't work very will
> on windows, where sockets aren't 0-indexed and aren't necessarily
> sequential. Any thoughts on how to get win32.c working?
win32.c is only accidentally included. libev uses its select backend and
file descriptors on windows too. This is an incompatibility I will not
address, as I think libev should use fds on all architectures (and the
typical way I see sockets being used for portable programs is using fds).
This is a wanted incompatibility (as it makes windows and unix compatible,
the fatc that I had to use os handles and not fds actually was one of the
problems I encountered with libevent).
> - I needed to include "-lm" and "-lrt" in my libraries to build.
> This isn't a bug, but it's something other people should know if
> they want to try this too.
Hmm, how does libevent handle that (I use the same confgiure etc. stuff as
libevent, and libevent also requires extra libraries such as -lrt).
Maybe it would be time for some libevent-config script for such stuff. While
-lm is likely always required (on unix clones), -lrt is truely optional and
depends on some configuration values.
> Once I did this, stuff seemed to work okay.
Thats quite a bit better than expected.
> Other people should try out libev with your existing applications too.
> If it works, and you don't run into any incompatibilities, that would
> be a point in favor of dropping something like the current libev core
> into a future libevent.
If that is intended, here are two things I would then add:
- event-style priority support (it would be nice to hear wether people
actually use that).
- a compatibility layer that (likely optionally) handles os handles instead
of fds on win32 when using the event emulation.
Both for backwards compatibility.
Thanks for your input!
--
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
