[Libevent-users] Compiling libevent in MacOS X with Xcode
I am a libevent newbye so it is possible that the fault is on my side ... but it seems to me that something should be changed in the header files in order to be able to compile libevent with Xcode. For example u_char definition is missed so the following lines should be added to events.h: #if defined(__APPLE__) typedef unsigned char u_char; #endif and what about _time.h? Is is really necessary or can I use the standard one? I receive an error: redefinition of struct timeval when I try to compile it. Any help? --- Marco Bambini http://www.sqlabs.net http://www.sqlabs.net/blog/ http://www.sqlabs.net/realsqlserver/ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] libevent win32 issues
Hi! While trying to port libev to win32, I ran into a number of issues with libevent proper (which of course still is the major part of the sources). Specifically: - evdns.c, httpc and other files include include files such as unistd.h, which are not available under windows. consequently, they do not even compile on win32 (tested with the visual c compiler). - is WIN32-Code/win32.c really the production-ready win32 backend? I can hardly believe this, as its basically not doing anything that the select backend doesn't do better and faster (for example, the win32 backend does a linear search over all(!) registered event watchers on each event_add/event_del/select call). additionally, signals are not being handled correctly (race conditions) on win32, but thats likely not a big deal on that platform. 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? (and yes, this is with libevent-1.3e proper, not anything I wrote, to avoid the off-topic argument again). PS: the good news is, the libev core is now fully working on cygwin and native win32 (and the EV module, too, except the DNS part, which I didn't want to port to win32). -- 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
Re: [Libevent-users] libevent win32 issues
On Tue, Nov 06, 2007 at 04:40:30PM -, 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=detailaid=1826615group_id=50884atid=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
Re: [Libevent-users] evdns C++ incompatibility
On Tue, Oct 02, 2007 at 02:49:28AM -0400, Roger Clark wrote:
At least on my system, gcc complains about 'class' being used in these
places in evdns.h:
Hi, Roger! I've checked in a possible fix for this as subversion
revision r486. The fix will appear in the first 1.4 release, assuming
that it doesn't break anything else too badly.
For backward compatibility with existing C code, evdns_server_question
is now defined as:
struct evdns_server_question {
int type;
#ifdef __cplusplus
int dns_question_class;
#else
/* You should refer to this field as dns_question_class. The
* name class works in C for backward compatibility, and will be
* removed in a future version. (1.5 or later). */
int class;
#define dns_question_class class
#endif
char name[1];
};
This should resolve bug 1826516 on the tracker. Please let us know if
there are any remaining C++ issues with the header, or if you run into
anything else like this?
many thanks,
--
Nick Mathewson
pgp6lTrpfiTim.pgp
Description: PGP signature
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
