On Wed, Apr 23, 2008 at 05:34:04PM +0400, Eugene 'HMage' Bujak wrote:
> Hi,
>
> I want to submit a more complete patch for VC6.
>
> This one makes all elements of the code compilable and this code is
> being used on a production-level project at work.
>
> The patch is in attachment. Compiles and works under VC6.
> * signal_test works.
> * timer_test works.
> * event_test fails due to the reason that win32 select() can't work on
> anything but network sockets.
>
> Most importantly, my code that runs perfectly well on unix (linux &
> freebsd) now runs on windows with little modification.
>
> But:
> * Didn't try to run any other tests since there are no project files for
> them.
> * Didn't test how mingw32 copes with these changes either.
Okay, I've gone through this patch again, under VC++2005. I think my
earlier issues still stand, so here's where we are:
> The main changes are:
> * INPUT and OUTPUT are defined in platform SDK, so I had to redefine
> them as EVRPC_INPUT and EVRPC_OUTPUT.
See notes in previous patch.
> * uint64_t on MSVC must be defined as unsigned __int64
> * int64_t on MSVC is to be defined as signed __int64
Should be fixed.
> * MSVC6 doesn't know about __func__ and the #ifdefs weren't guarding
> against them good enough.
This is just the changes in the sample dir, right? As near as I can
tell, the change in config.h shouldn't be necessary, yes?
> * winsock2.h sometimes was included after windows.h, that lead to
> compiler errors in libevent.
Fixed.
> * select.c can be painlessly excluded from compilation in win32, but I
> still fixed it's compilation.
There's no point in including it; it shouldn't be in the win32 project.
> * Winsock library needs to be initialized and freed explicitly on win32.
Haven't applied yet.
> * http.c was using sockaddr_storage. There isn't one in MSVC. Using
> sockaddr is good enough for MSVC.
Checking for msc isn't right here: newer sdks do indeed seem to define
sockaddr_storage.
> * There are tons of compiler warnings regarding "do {} while(0);"
Sorry, which part fixes this?
> * I took the liberty to add #pragma to the WIN32-section of the event.h
> so that there's no need to put ws2_32 library into the linker explicitly.
> * There's no NFDBITS in msvc.
Shouldn't be needed if we don't use the select.c file.
> * vsnprintf() is _vsnprintf() for some weird reason on win32.
Actually, this underscores a deeper problem. Windows vsnprintf
returns -1 if the result is too big for the buffer, but this is not
what libevent expects in a lot of places. We need to solve this one.
I'm filing a bug here so we don't forget about it.
> * I've had to bump tv->tv_usec to 1000 to prevent eating 100% of the cpu
> core in win32 dispatch when using timers with events each 10ms or so.
Hm? If the timers are happening every 10 ms, then the usec field
should be at least 10000 already. If there's a small example here to
help me wrap my head around the problem, that would be great.
> * Also I've provided a gettimeofday() wrapper that uses timeGetTime()
> instead of much slower _ftime().
Unfortunately, this will probably turn out to give unreliable results,
as it wraps every 49 days. Thus, roughly 1 day out of 50, users'
timers will all go off way too early or not at all, depending. Still,
it's a shame to use a slow time interface. I hear
GetSystemTimeAsFileTime() [or whatever it's called] has a high
resolution, but I hear it preforms badly on win9x. Perhaps if we're
feeling nutty, we could cobble something monotonic together out of
time() and timeGetTime(), like:
int
fake_gettimeofday(struct timeval *tv, struct timezone *tz) {
/* Threadsafety? What threadsafety? Also, not tested. */
static DWORD last_timeGetTime_result = 0;
static long seconds_offset = 0;
DWORD now = timeGetTime();
time_t seconds = now / 1000;
if (!seconds_offset || now < last_timeGetTime_result) {
/* Called for the first time, or wrapping around. */
seconds_offset = time(NULL) - seconds;
}
tv->tv_sec = seconds + seconds_offset;
tv->tv_usec = (now % 1000) * 1000;
last_timeGetTime_result = now;
return 0;
}
In any case, 1.4.4 will call gettimeofday a lot less frequently than
1.4.3; maybe the ftime() call won't hurt as much now?
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
