On Mon, Jun 01, 2009 at 05:38:58PM +0100, James Mansion wrote:
> Nick Mathewson wrote:
> >Good morning, evening, night, or afternoon!
> >
> >The first alpha release in the long-promised Libevent 2.0 series
> >is finally out. You can download Libevent 2.0.1-alpha from
> > http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz
> >
> >
> I have a number of patches designed to make the build on Win32 smoother.
> I have the regress application building, although it does not run reliably.
>
> The biggest changes are in the rpcgen program - most of the others are
> minor.
>
> Where should I send the patches?
Try the sourceforge patch tracker at
https://sourceforge.net/tracker/?group_id=50884&atid=461324
> I have a waf script that automates building the whole lot including
> doing the config
> stage if anyone is interested. Its not finalised (and I have yet to
> make it work on
> UNIX) but it may help dev without fiddling with msdev projects all the time.
>
Neat stuff.
> The result fails the same way as the msdev build when a debug build is used,
> and fails in other ways when an optimised build is done.
>
> What is the expectation for regress.exe --no-fork on Windows?
The expectation for regress.exe on windows is that it pass with no
errors. (FWIW, the --no-fork option is only for debugging and
internal use; using it with more than one test at a time is likely not
to work.)
> At the moment
> it fails in test_edgetriggered because the 'fd' passed to write isn't
> appropriate.
Weirdly, it works on mingw, which is why I hadn't noticed it. [I
guess this is what happens from not having a working MSVC build.] But
yeah, that should be a send, not a write. I've just fixed that in
the repository.
> I can't help feeling that the attempt to use raw UNIX-style APIs and fd
> abstraction
> on Windows is likely to be fraught - its easy enough to create an
> abstraction that
> works OK, but doing so using the raw UNIX abstractions seems to me likely to
> end up fighting the differences between sockets, file handles, and fd as
> emulated by
> C runtime on Windows.
>
> It may be possible to bully it to work eventually, but its going to be
> very messy.
>
> Is it really so unpalatable to break the API with the major version change?
Heh. Unless somebody volunteers to rewrite all of *my*
currently-working code that was written to use the existing APIs, I
will sure find it unpalatable to break them. I suspect that other
people who have written applications with the current Libevent will
feel the same way.
If there's something that really sucks in a current interface, the
right approach is probably to add a _new_ API that can do the right
thing, while we deprecate the old API but keep it working. That's
what we did with event_set() in 2.0.1.
yrs,
--
Nick
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
