On Tue, Nov 06, 2007 at 04:40:30PM -0000, Toby Douglass wrote: > Nick Mathewson wrote: > > On Tue, Nov 06, 2007 at 05:09:07PM +0100, Marc Lehmann wrote: > > > There are two factors that keep the select() implementation on win32 > > from using the same strategy/code as the one : > > > > 1) win32's select() doesn't use bitfields; it uses an array of > > sockets. This is because... > > > > 2) win32 sockets, unlike unix fds, are not consecutively numbered > > integers starting at 0. Thus, it is _NOT_ a good idea to use an > > array to map fds to events like select.c does; your array would > > be enormous and sparse. > > > > A balanced tree implementation might an improvement here. It would be > > nice if somebody would step up and write one. > > select() under win32 only works on sockets, so it's only purpose is socket > selection. Given that, select() is a poor choice - I/O completion ports > are much better; for one thing, they scale. libiocp exists, although I > don't know at all what would be involved in the integration with libevent.
Please see all the past discussions on this. :) IOCP is a good match for the bufferevents interface and there has indeed been some work to try to get an IOCP-based bufferevents interface working. See http://sourceforge.net/tracker/index.php?func=detail&aid=1826615&group_id=50884&atid=461325 IOCP doesn't fit very cleanly into the interface supported by the rest of libevent, however: the basic event types expect that the backend will notify them when a blocked operation can be reattempted. IOCP, on the other hand, notifies the application when pending operation is finished. Then again, it may be possible to shoehorn IOCP's behavior into the select/poll/etc style interface of the rest of libevent. I'd love to be proven wrong about this. :) There are other ways to do fast IO on win32. WSAWaitForMultipleEvents is supposedly pretty fast, but it doesn't accept more than 64 sockets, so you need to get fancy with threads to make it work. In other words, "Yes, we can do better, but there will be programming involved. Somebody will have to do that programming before we do better." ;) > >> Looking around with google it seems that indeed, evdns et. al does not > >> build on windows (except when using e.g. cygwin, but thats trivial). > >> > >> So I wonder if libevent as a whole is supported under windows at all in > >> current versions? > > > > I'd like to have everything work on win32. Trunk compiles on mingw > > fine. I would like it also to compile under MSVC, but I don't have a > > copy of MSVC. That's why diffs would be nice. :) > > MS offer a free command line compiler and SDK. Given they're free and > compatable with the commercial build environments, would they be a viable > choice of Win32 build environment? I seem to recall being told about licensing issues, but the person who told me may have been an alarmist. I'll try it out some time in the next few weeks if I can. In the mean time, feel free to give it a try; see what happens; see what you can fix; send in a diff? yrs, -- Nick Mathewson
pgp0xExUKDNys.pgp
Description: PGP signature
_______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
