libevent/test/Makefile.nmake

78 lines
2.3 KiB
Makefile
Raw Normal View History

# WATCH OUT! This makefile is a work in progress. -*- makefile -*-
!IFDEF OPENSSL_DIR
SSL_CFLAGS=/I$(OPENSSL_DIR)\include /DEVENT__HAVE_OPENSSL
SSL_OBJS=regress_ssl.obj
SSL_LIBS=..\libevent_openssl.lib $(OPENSSL_DIR)\lib\libeay32.lib $(OPENSSL_DIR)\lib\ssleay32.lib
!ELSE
SSL_CFLAGS=
SSL_OBJS=
SSL_LIBS=
!ENDIF
CFLAGS=/I.. /I../WIN32-Code /I../include /I../compat /DHAVE_CONFIG_H /DTINYTEST_LOCAL $(SSL_CFLAGS)
CFLAGS=$(CFLAGS) /Ox /W3 /wd4996 /nologo
REGRESS_OBJS=regress.obj regress_buffer.obj regress_http.obj regress_dns.obj \
regress_testutils.obj \
regress_rpc.obj regress.gen.obj \
regress_et.obj regress_bufferevent.obj \
regress_listener.obj regress_util.obj tinytest.obj \
regress_main.obj regress_minheap.obj regress_iocp.obj \
regress_thread.obj $(SSL_OBJS)
OTHER_OBJS=test-init.obj test-eof.obj test-weof.obj test-time.obj \
Possible fix to 100% cpu usage with epoll and openssl I'm running a fairly simple bit of test code using libevent2 with epoll and openssl bufferevents and I've run into a 100% cpu usage problem. Looking into it 100% usage was caused by epoll_wait constantly returning write events on the openssl socket when it shouldn't really have been looking for write events at all (N_ACTIVE_CALLBACKS() was returning 0 also). Looking a bit deeper eventbuffer_openssl socket seems to be requesting that the EV_WRITE event be removed when it should, but the event isn't actually being removed from epoll. Continuing to follow this I think I've found a bug in event_changelist_del. For evpoll event_del calls event_changelist_del which caches the change which is then actioned later when evpoll_dispatch is called. In event_changlist_del there is a check so that if the currently changed action is an add then the cached action is changed to a no-op rather than a delete (which makes sense). The problem arises if there are more than two add or delete operations between calls to dispatch, in this case it's possible that the delete is turned into a no-op when it shouldn't have been. For example starting with the event on, a delete followed by an add and then another delete results in a no-op when it should have been a delete (I added a fair bit of debug output that seems to confirm this behaviour). I've applied a small change that checks the original old_event stored with the change and only converts the delete to a no-op if the event isn't on in old_event. This seems to have fixed my problem.
2010-07-19 13:44:56 +12:00
bench.obj bench_cascade.obj bench_http.obj bench_httpclient.obj \
test-changelist.obj \
print-winsock-errors.obj
PROGRAMS=regress.exe \
Possible fix to 100% cpu usage with epoll and openssl I'm running a fairly simple bit of test code using libevent2 with epoll and openssl bufferevents and I've run into a 100% cpu usage problem. Looking into it 100% usage was caused by epoll_wait constantly returning write events on the openssl socket when it shouldn't really have been looking for write events at all (N_ACTIVE_CALLBACKS() was returning 0 also). Looking a bit deeper eventbuffer_openssl socket seems to be requesting that the EV_WRITE event be removed when it should, but the event isn't actually being removed from epoll. Continuing to follow this I think I've found a bug in event_changelist_del. For evpoll event_del calls event_changelist_del which caches the change which is then actioned later when evpoll_dispatch is called. In event_changlist_del there is a check so that if the currently changed action is an add then the cached action is changed to a no-op rather than a delete (which makes sense). The problem arises if there are more than two add or delete operations between calls to dispatch, in this case it's possible that the delete is turned into a no-op when it shouldn't have been. For example starting with the event on, a delete followed by an add and then another delete results in a no-op when it should have been a delete (I added a fair bit of debug output that seems to confirm this behaviour). I've applied a small change that checks the original old_event stored with the change and only converts the delete to a no-op if the event isn't on in old_event. This seems to have fixed my problem.
2010-07-19 13:44:56 +12:00
test-init.exe test-eof.exe test-weof.exe test-time.exe \
test-changelist.exe \
print-winsock-errors.exe
# Disabled for now:
# bench.exe bench_cascade.exe bench_http.exe bench_httpclient.exe
2010-01-23 20:07:05 -05:00
LIBS=..\libevent.lib ws2_32.lib shell32.lib advapi32.lib
all: $(PROGRAMS)
regress.exe: $(REGRESS_OBJS)
$(CC) $(CFLAGS) $(LIBS) $(SSL_LIBS) $(REGRESS_OBJS)
test-init.exe: test-init.obj
$(CC) $(CFLAGS) $(LIBS) test-init.obj
test-eof.exe: test-eof.obj
$(CC) $(CFLAGS) $(LIBS) test-eof.obj
Possible fix to 100% cpu usage with epoll and openssl I'm running a fairly simple bit of test code using libevent2 with epoll and openssl bufferevents and I've run into a 100% cpu usage problem. Looking into it 100% usage was caused by epoll_wait constantly returning write events on the openssl socket when it shouldn't really have been looking for write events at all (N_ACTIVE_CALLBACKS() was returning 0 also). Looking a bit deeper eventbuffer_openssl socket seems to be requesting that the EV_WRITE event be removed when it should, but the event isn't actually being removed from epoll. Continuing to follow this I think I've found a bug in event_changelist_del. For evpoll event_del calls event_changelist_del which caches the change which is then actioned later when evpoll_dispatch is called. In event_changlist_del there is a check so that if the currently changed action is an add then the cached action is changed to a no-op rather than a delete (which makes sense). The problem arises if there are more than two add or delete operations between calls to dispatch, in this case it's possible that the delete is turned into a no-op when it shouldn't have been. For example starting with the event on, a delete followed by an add and then another delete results in a no-op when it should have been a delete (I added a fair bit of debug output that seems to confirm this behaviour). I've applied a small change that checks the original old_event stored with the change and only converts the delete to a no-op if the event isn't on in old_event. This seems to have fixed my problem.
2010-07-19 13:44:56 +12:00
test-changelist.exe: test-changelist.obj
$(CC) $(CFLAGS) $(LIBS) test-changelist.obj
test-weof.exe: test-weof.obj
$(CC) $(CFLAGS) $(LIBS) test-weof.obj
test-time.exe: test-time.obj
$(CC) $(CFLAGS) $(LIBS) test-time.obj
print-winsock-errors.exe: print-winsock-errors.obj
$(CC) $(CFLAGS) $(LIBS) print-winsock-errors.obj
bench.exe: bench.obj
$(CC) $(CFLAGS) $(LIBS) bench.obj
bench_cascade.exe: bench_cascade.obj
$(CC) $(CFLAGS) $(LIBS) bench_cascade.obj
bench_http.exe: bench_http.obj
$(CC) $(CFLAGS) $(LIBS) bench_http.obj
bench_httpclient.exe: bench_httpclient.obj
$(CC) $(CFLAGS) $(LIBS) bench_httpclient.obj
regress.gen.c regress.gen.h: regress.rpc ../event_rpcgen.py
echo // > regress.gen.c
echo #define NO_PYTHON_EXISTS > regress.gen.h
-python ..\event_rpcgen.py regress.rpc
clean:
-del $(REGRESS_OBJS)
-del $(OTHER_OBJS)
-del $(PROGRAMS)