libevent/test/test-changelist.c

228 lines
5.8 KiB
C
Raw Normal View History

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
/*
2012-02-10 17:29:53 -05:00
* Copyright (c) 2010-2012 Niels Provos and Nick Mathewson
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
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
*/
#include "event2/event-config.h"
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
#ifdef _WIN32
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
#include <winsock2.h>
#include <windows.h>
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
#else
#include <unistd.h>
#endif
#include <sys/types.h>
#include <sys/stat.h>
Convert event-config.h macros to avoid reserved identifiers C reserves all identifiers beginning with an underscore for system use. But we had been mangling our autoconf identifiers with the prefix "_EVENT_" to avoid conflict with other programs. Instead, we will now use the prefix "EVENT__". With any luck, the double-underscore will still hint "here be dragons" to anybody tempted to think that event-config.h is a stable api. This is an automatically generated patch. The script that produced it was made by running this script over config.h.in: ===== #!/usr/bin/perl -w # Run this on config.h.in use strict; my %macros = (); while (<>) { if (/^# *undef +([A-Za-z0-9_]+)/) { $macros{$1} = 1; } } print "#!/usr/bin/perl -w -i -p\n\n"; for my $k (sort keys %macros) { print "s/(?<![A-Za-z0-9_])_EVENT_$k(?![A-Za-z0-9_])/EVENT__$k/g;\n"; } == And the script that it generated was then run over all .c and .h files: #!/usr/bin/perl -w -i -p s/(?<![A-Za-z0-9_])_EVENT_DISABLE_DEBUG_MODE(?![A-Za-z0-9_])/EVENT__DISABLE_DEBUG_MODE/g; s/(?<![A-Za-z0-9_])_EVENT_DISABLE_MM_REPLACEMENT(?![A-Za-z0-9_])/EVENT__DISABLE_MM_REPLACEMENT/g; s/(?<![A-Za-z0-9_])_EVENT_DISABLE_THREAD_SUPPORT(?![A-Za-z0-9_])/EVENT__DISABLE_THREAD_SUPPORT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ACCEPT4(?![A-Za-z0-9_])/EVENT__HAVE_ACCEPT4/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARC4RANDOM(?![A-Za-z0-9_])/EVENT__HAVE_ARC4RANDOM/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARC4RANDOM_BUF(?![A-Za-z0-9_])/EVENT__HAVE_ARC4RANDOM_BUF/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARPA_INET_H(?![A-Za-z0-9_])/EVENT__HAVE_ARPA_INET_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_CLOCK_GETTIME(?![A-Za-z0-9_])/EVENT__HAVE_CLOCK_GETTIME/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_CTL_KERN(?![A-Za-z0-9_])/EVENT__HAVE_DECL_CTL_KERN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_KERN_ARND(?![A-Za-z0-9_])/EVENT__HAVE_DECL_KERN_ARND/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_KERN_RANDOM(?![A-Za-z0-9_])/EVENT__HAVE_DECL_KERN_RANDOM/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_RANDOM_UUID(?![A-Za-z0-9_])/EVENT__HAVE_DECL_RANDOM_UUID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DEVPOLL(?![A-Za-z0-9_])/EVENT__HAVE_DEVPOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DLFCN_H(?![A-Za-z0-9_])/EVENT__HAVE_DLFCN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL_CREATE1(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL_CREATE1/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL_CTL(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL_CTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EVENTFD(?![A-Za-z0-9_])/EVENT__HAVE_EVENTFD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EVENT_PORTS(?![A-Za-z0-9_])/EVENT__HAVE_EVENT_PORTS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FCNTL(?![A-Za-z0-9_])/EVENT__HAVE_FCNTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FCNTL_H(?![A-Za-z0-9_])/EVENT__HAVE_FCNTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FD_MASK(?![A-Za-z0-9_])/EVENT__HAVE_FD_MASK/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETADDRINFO(?![A-Za-z0-9_])/EVENT__HAVE_GETADDRINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETEGID(?![A-Za-z0-9_])/EVENT__HAVE_GETEGID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETEUID(?![A-Za-z0-9_])/EVENT__HAVE_GETEUID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_3_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_3_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_5_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_5_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_6_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_6_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETIFADDRS(?![A-Za-z0-9_])/EVENT__HAVE_GETIFADDRS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETNAMEINFO(?![A-Za-z0-9_])/EVENT__HAVE_GETNAMEINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETPROTOBYNUMBER(?![A-Za-z0-9_])/EVENT__HAVE_GETPROTOBYNUMBER/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETSERVBYNAME(?![A-Za-z0-9_])/EVENT__HAVE_GETSERVBYNAME/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETTIMEOFDAY(?![A-Za-z0-9_])/EVENT__HAVE_GETTIMEOFDAY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_IFADDRS_H(?![A-Za-z0-9_])/EVENT__HAVE_IFADDRS_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_ATON(?![A-Za-z0-9_])/EVENT__HAVE_INET_ATON/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_NTOP(?![A-Za-z0-9_])/EVENT__HAVE_INET_NTOP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_PTON(?![A-Za-z0-9_])/EVENT__HAVE_INET_PTON/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INTTYPES_H(?![A-Za-z0-9_])/EVENT__HAVE_INTTYPES_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ISSETUGID(?![A-Za-z0-9_])/EVENT__HAVE_ISSETUGID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_KQUEUE(?![A-Za-z0-9_])/EVENT__HAVE_KQUEUE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_LIBZ(?![A-Za-z0-9_])/EVENT__HAVE_LIBZ/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_MEMORY_H(?![A-Za-z0-9_])/EVENT__HAVE_MEMORY_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_MMAP(?![A-Za-z0-9_])/EVENT__HAVE_MMAP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NANOSLEEP(?![A-Za-z0-9_])/EVENT__HAVE_NANOSLEEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETDB_H(?![A-Za-z0-9_])/EVENT__HAVE_NETDB_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_IN6_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_IN6_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_IN_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_IN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_TCP_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_TCP_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_OPENSSL(?![A-Za-z0-9_])/EVENT__HAVE_OPENSSL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PIPE(?![A-Za-z0-9_])/EVENT__HAVE_PIPE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PIPE2(?![A-Za-z0-9_])/EVENT__HAVE_PIPE2/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_POLL(?![A-Za-z0-9_])/EVENT__HAVE_POLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_POLL_H(?![A-Za-z0-9_])/EVENT__HAVE_POLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PORT_CREATE(?![A-Za-z0-9_])/EVENT__HAVE_PORT_CREATE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PORT_H(?![A-Za-z0-9_])/EVENT__HAVE_PORT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PTHREAD(?![A-Za-z0-9_])/EVENT__HAVE_PTHREAD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PTHREADS(?![A-Za-z0-9_])/EVENT__HAVE_PTHREADS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PUTENV(?![A-Za-z0-9_])/EVENT__HAVE_PUTENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SA_FAMILY_T(?![A-Za-z0-9_])/EVENT__HAVE_SA_FAMILY_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SELECT(?![A-Za-z0-9_])/EVENT__HAVE_SELECT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SENDFILE(?![A-Za-z0-9_])/EVENT__HAVE_SENDFILE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETENV(?![A-Za-z0-9_])/EVENT__HAVE_SETENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETFD(?![A-Za-z0-9_])/EVENT__HAVE_SETFD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETRLIMIT(?![A-Za-z0-9_])/EVENT__HAVE_SETRLIMIT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SIGACTION(?![A-Za-z0-9_])/EVENT__HAVE_SIGACTION/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SIGNAL(?![A-Za-z0-9_])/EVENT__HAVE_SIGNAL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SPLICE(?![A-Za-z0-9_])/EVENT__HAVE_SPLICE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDARG_H(?![A-Za-z0-9_])/EVENT__HAVE_STDARG_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDDEF_H(?![A-Za-z0-9_])/EVENT__HAVE_STDDEF_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDINT_H(?![A-Za-z0-9_])/EVENT__HAVE_STDINT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDLIB_H(?![A-Za-z0-9_])/EVENT__HAVE_STDLIB_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRINGS_H(?![A-Za-z0-9_])/EVENT__HAVE_STRINGS_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRING_H(?![A-Za-z0-9_])/EVENT__HAVE_STRING_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRLCPY(?![A-Za-z0-9_])/EVENT__HAVE_STRLCPY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRSEP(?![A-Za-z0-9_])/EVENT__HAVE_STRSEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRTOK_R(?![A-Za-z0-9_])/EVENT__HAVE_STRTOK_R/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRTOLL(?![A-Za-z0-9_])/EVENT__HAVE_STRTOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_ADDRINFO(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_ADDRINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR_S6_ADDR16(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR_S6_ADDR16/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR_S6_ADDR32(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR_S6_ADDR32/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN6(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN6/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN6_SIN6_LEN(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN6_SIN6_LEN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN_SIN_LEN(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN_SIN_LEN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYSCTL(?![A-Za-z0-9_])/EVENT__HAVE_SYSCTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_DEVPOLL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_DEVPOLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EPOLL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EPOLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EVENTFD_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EVENTFD_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EVENT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EVENT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_IOCTL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_IOCTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_MMAN_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_MMAN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_PARAM_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_PARAM_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_QUEUE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_QUEUE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_RESOURCE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_RESOURCE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SELECT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SELECT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SENDFILE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SENDFILE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SOCKET_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SOCKET_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_STAT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_STAT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SYSCTL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SYSCTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_TIME_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_TIME_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_TYPES_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_TYPES_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_UIO_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_UIO_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_WAIT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_WAIT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TAILQFOREACH(?![A-Za-z0-9_])/EVENT__HAVE_TAILQFOREACH/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERADD(?![A-Za-z0-9_])/EVENT__HAVE_TIMERADD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERCLEAR(?![A-Za-z0-9_])/EVENT__HAVE_TIMERCLEAR/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERCMP(?![A-Za-z0-9_])/EVENT__HAVE_TIMERCMP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERISSET(?![A-Za-z0-9_])/EVENT__HAVE_TIMERISSET/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT16_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT16_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT32_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT32_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT64_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT64_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT8_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT8_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINTPTR_T(?![A-Za-z0-9_])/EVENT__HAVE_UINTPTR_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UNISTD_H(?![A-Za-z0-9_])/EVENT__HAVE_UNISTD_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UNSETENV(?![A-Za-z0-9_])/EVENT__HAVE_UNSETENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_USLEEP(?![A-Za-z0-9_])/EVENT__HAVE_USLEEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_VASPRINTF(?![A-Za-z0-9_])/EVENT__HAVE_VASPRINTF/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_WORKING_KQUEUE(?![A-Za-z0-9_])/EVENT__HAVE_WORKING_KQUEUE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ZLIB_H(?![A-Za-z0-9_])/EVENT__HAVE_ZLIB_H/g; s/(?<![A-Za-z0-9_])_EVENT_LT_OBJDIR(?![A-Za-z0-9_])/EVENT__LT_OBJDIR/g; s/(?<![A-Za-z0-9_])_EVENT_NO_MINUS_C_MINUS_O(?![A-Za-z0-9_])/EVENT__NO_MINUS_C_MINUS_O/g; s/(?<![A-Za-z0-9_])_EVENT_NUMERIC_VERSION(?![A-Za-z0-9_])/EVENT__NUMERIC_VERSION/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE(?![A-Za-z0-9_])/EVENT__PACKAGE/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_BUGREPORT(?![A-Za-z0-9_])/EVENT__PACKAGE_BUGREPORT/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_NAME(?![A-Za-z0-9_])/EVENT__PACKAGE_NAME/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_STRING(?![A-Za-z0-9_])/EVENT__PACKAGE_STRING/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_TARNAME(?![A-Za-z0-9_])/EVENT__PACKAGE_TARNAME/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_URL(?![A-Za-z0-9_])/EVENT__PACKAGE_URL/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_VERSION(?![A-Za-z0-9_])/EVENT__PACKAGE_VERSION/g; s/(?<![A-Za-z0-9_])_EVENT_PTHREAD_CREATE_JOINABLE(?![A-Za-z0-9_])/EVENT__PTHREAD_CREATE_JOINABLE/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_INT(?![A-Za-z0-9_])/EVENT__SIZEOF_INT/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_LONG(?![A-Za-z0-9_])/EVENT__SIZEOF_LONG/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_LONG_LONG(?![A-Za-z0-9_])/EVENT__SIZEOF_LONG_LONG/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_OFF_T(?![A-Za-z0-9_])/EVENT__SIZEOF_OFF_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_PTHREAD_T(?![A-Za-z0-9_])/EVENT__SIZEOF_PTHREAD_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_SHORT(?![A-Za-z0-9_])/EVENT__SIZEOF_SHORT/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_SIZE_T(?![A-Za-z0-9_])/EVENT__SIZEOF_SIZE_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_VOID_P(?![A-Za-z0-9_])/EVENT__SIZEOF_VOID_P/g; s/(?<![A-Za-z0-9_])_EVENT_STDC_HEADERS(?![A-Za-z0-9_])/EVENT__STDC_HEADERS/g; s/(?<![A-Za-z0-9_])_EVENT_TIME_WITH_SYS_TIME(?![A-Za-z0-9_])/EVENT__TIME_WITH_SYS_TIME/g; s/(?<![A-Za-z0-9_])_EVENT_VERSION(?![A-Za-z0-9_])/EVENT__VERSION/g; s/(?<![A-Za-z0-9_])_EVENT__ALL_SOURCE(?![A-Za-z0-9_])/EVENT___ALL_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__FILE_OFFSET_BITS(?![A-Za-z0-9_])/EVENT___FILE_OFFSET_BITS/g; s/(?<![A-Za-z0-9_])_EVENT__GNU_SOURCE(?![A-Za-z0-9_])/EVENT___GNU_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__LARGE_FILES(?![A-Za-z0-9_])/EVENT___LARGE_FILES/g; s/(?<![A-Za-z0-9_])_EVENT__MINIX(?![A-Za-z0-9_])/EVENT___MINIX/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_1_SOURCE(?![A-Za-z0-9_])/EVENT___POSIX_1_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_PTHREAD_SEMANTICS(?![A-Za-z0-9_])/EVENT___POSIX_PTHREAD_SEMANTICS/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_SOURCE(?![A-Za-z0-9_])/EVENT___POSIX_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__TANDEM_SOURCE(?![A-Za-z0-9_])/EVENT___TANDEM_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT___EXTENSIONS__(?![A-Za-z0-9_])/EVENT____EXTENSIONS__/g; s/(?<![A-Za-z0-9_])_EVENT___func__(?![A-Za-z0-9_])/EVENT____func__/g; s/(?<![A-Za-z0-9_])_EVENT_const(?![A-Za-z0-9_])/EVENT__const/g; s/(?<![A-Za-z0-9_])_EVENT_inline(?![A-Za-z0-9_])/EVENT__inline/g; s/(?<![A-Za-z0-9_])_EVENT_pid_t(?![A-Za-z0-9_])/EVENT__pid_t/g; s/(?<![A-Za-z0-9_])_EVENT_size_t(?![A-Za-z0-9_])/EVENT__size_t/g; s/(?<![A-Za-z0-9_])_EVENT_socklen_t(?![A-Za-z0-9_])/EVENT__socklen_t/g; s/(?<![A-Za-z0-9_])_EVENT_ssize_t(?![A-Za-z0-9_])/EVENT__ssize_t/g;
2012-02-29 15:07:31 -05:00
#ifdef EVENT__HAVE_SYS_TIME_H
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
#include <sys/time.h>
#endif
Convert event-config.h macros to avoid reserved identifiers C reserves all identifiers beginning with an underscore for system use. But we had been mangling our autoconf identifiers with the prefix "_EVENT_" to avoid conflict with other programs. Instead, we will now use the prefix "EVENT__". With any luck, the double-underscore will still hint "here be dragons" to anybody tempted to think that event-config.h is a stable api. This is an automatically generated patch. The script that produced it was made by running this script over config.h.in: ===== #!/usr/bin/perl -w # Run this on config.h.in use strict; my %macros = (); while (<>) { if (/^# *undef +([A-Za-z0-9_]+)/) { $macros{$1} = 1; } } print "#!/usr/bin/perl -w -i -p\n\n"; for my $k (sort keys %macros) { print "s/(?<![A-Za-z0-9_])_EVENT_$k(?![A-Za-z0-9_])/EVENT__$k/g;\n"; } == And the script that it generated was then run over all .c and .h files: #!/usr/bin/perl -w -i -p s/(?<![A-Za-z0-9_])_EVENT_DISABLE_DEBUG_MODE(?![A-Za-z0-9_])/EVENT__DISABLE_DEBUG_MODE/g; s/(?<![A-Za-z0-9_])_EVENT_DISABLE_MM_REPLACEMENT(?![A-Za-z0-9_])/EVENT__DISABLE_MM_REPLACEMENT/g; s/(?<![A-Za-z0-9_])_EVENT_DISABLE_THREAD_SUPPORT(?![A-Za-z0-9_])/EVENT__DISABLE_THREAD_SUPPORT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ACCEPT4(?![A-Za-z0-9_])/EVENT__HAVE_ACCEPT4/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARC4RANDOM(?![A-Za-z0-9_])/EVENT__HAVE_ARC4RANDOM/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARC4RANDOM_BUF(?![A-Za-z0-9_])/EVENT__HAVE_ARC4RANDOM_BUF/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ARPA_INET_H(?![A-Za-z0-9_])/EVENT__HAVE_ARPA_INET_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_CLOCK_GETTIME(?![A-Za-z0-9_])/EVENT__HAVE_CLOCK_GETTIME/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_CTL_KERN(?![A-Za-z0-9_])/EVENT__HAVE_DECL_CTL_KERN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_KERN_ARND(?![A-Za-z0-9_])/EVENT__HAVE_DECL_KERN_ARND/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_KERN_RANDOM(?![A-Za-z0-9_])/EVENT__HAVE_DECL_KERN_RANDOM/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DECL_RANDOM_UUID(?![A-Za-z0-9_])/EVENT__HAVE_DECL_RANDOM_UUID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DEVPOLL(?![A-Za-z0-9_])/EVENT__HAVE_DEVPOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_DLFCN_H(?![A-Za-z0-9_])/EVENT__HAVE_DLFCN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL_CREATE1(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL_CREATE1/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EPOLL_CTL(?![A-Za-z0-9_])/EVENT__HAVE_EPOLL_CTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EVENTFD(?![A-Za-z0-9_])/EVENT__HAVE_EVENTFD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_EVENT_PORTS(?![A-Za-z0-9_])/EVENT__HAVE_EVENT_PORTS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FCNTL(?![A-Za-z0-9_])/EVENT__HAVE_FCNTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FCNTL_H(?![A-Za-z0-9_])/EVENT__HAVE_FCNTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_FD_MASK(?![A-Za-z0-9_])/EVENT__HAVE_FD_MASK/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETADDRINFO(?![A-Za-z0-9_])/EVENT__HAVE_GETADDRINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETEGID(?![A-Za-z0-9_])/EVENT__HAVE_GETEGID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETEUID(?![A-Za-z0-9_])/EVENT__HAVE_GETEUID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_3_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_3_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_5_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_5_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETHOSTBYNAME_R_6_ARG(?![A-Za-z0-9_])/EVENT__HAVE_GETHOSTBYNAME_R_6_ARG/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETIFADDRS(?![A-Za-z0-9_])/EVENT__HAVE_GETIFADDRS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETNAMEINFO(?![A-Za-z0-9_])/EVENT__HAVE_GETNAMEINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETPROTOBYNUMBER(?![A-Za-z0-9_])/EVENT__HAVE_GETPROTOBYNUMBER/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETSERVBYNAME(?![A-Za-z0-9_])/EVENT__HAVE_GETSERVBYNAME/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_GETTIMEOFDAY(?![A-Za-z0-9_])/EVENT__HAVE_GETTIMEOFDAY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_IFADDRS_H(?![A-Za-z0-9_])/EVENT__HAVE_IFADDRS_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_ATON(?![A-Za-z0-9_])/EVENT__HAVE_INET_ATON/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_NTOP(?![A-Za-z0-9_])/EVENT__HAVE_INET_NTOP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INET_PTON(?![A-Za-z0-9_])/EVENT__HAVE_INET_PTON/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_INTTYPES_H(?![A-Za-z0-9_])/EVENT__HAVE_INTTYPES_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ISSETUGID(?![A-Za-z0-9_])/EVENT__HAVE_ISSETUGID/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_KQUEUE(?![A-Za-z0-9_])/EVENT__HAVE_KQUEUE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_LIBZ(?![A-Za-z0-9_])/EVENT__HAVE_LIBZ/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_MEMORY_H(?![A-Za-z0-9_])/EVENT__HAVE_MEMORY_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_MMAP(?![A-Za-z0-9_])/EVENT__HAVE_MMAP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NANOSLEEP(?![A-Za-z0-9_])/EVENT__HAVE_NANOSLEEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETDB_H(?![A-Za-z0-9_])/EVENT__HAVE_NETDB_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_IN6_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_IN6_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_IN_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_IN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_NETINET_TCP_H(?![A-Za-z0-9_])/EVENT__HAVE_NETINET_TCP_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_OPENSSL(?![A-Za-z0-9_])/EVENT__HAVE_OPENSSL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PIPE(?![A-Za-z0-9_])/EVENT__HAVE_PIPE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PIPE2(?![A-Za-z0-9_])/EVENT__HAVE_PIPE2/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_POLL(?![A-Za-z0-9_])/EVENT__HAVE_POLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_POLL_H(?![A-Za-z0-9_])/EVENT__HAVE_POLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PORT_CREATE(?![A-Za-z0-9_])/EVENT__HAVE_PORT_CREATE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PORT_H(?![A-Za-z0-9_])/EVENT__HAVE_PORT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PTHREAD(?![A-Za-z0-9_])/EVENT__HAVE_PTHREAD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PTHREADS(?![A-Za-z0-9_])/EVENT__HAVE_PTHREADS/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_PUTENV(?![A-Za-z0-9_])/EVENT__HAVE_PUTENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SA_FAMILY_T(?![A-Za-z0-9_])/EVENT__HAVE_SA_FAMILY_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SELECT(?![A-Za-z0-9_])/EVENT__HAVE_SELECT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SENDFILE(?![A-Za-z0-9_])/EVENT__HAVE_SENDFILE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETENV(?![A-Za-z0-9_])/EVENT__HAVE_SETENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETFD(?![A-Za-z0-9_])/EVENT__HAVE_SETFD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SETRLIMIT(?![A-Za-z0-9_])/EVENT__HAVE_SETRLIMIT/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SIGACTION(?![A-Za-z0-9_])/EVENT__HAVE_SIGACTION/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SIGNAL(?![A-Za-z0-9_])/EVENT__HAVE_SIGNAL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SPLICE(?![A-Za-z0-9_])/EVENT__HAVE_SPLICE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDARG_H(?![A-Za-z0-9_])/EVENT__HAVE_STDARG_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDDEF_H(?![A-Za-z0-9_])/EVENT__HAVE_STDDEF_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDINT_H(?![A-Za-z0-9_])/EVENT__HAVE_STDINT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STDLIB_H(?![A-Za-z0-9_])/EVENT__HAVE_STDLIB_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRINGS_H(?![A-Za-z0-9_])/EVENT__HAVE_STRINGS_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRING_H(?![A-Za-z0-9_])/EVENT__HAVE_STRING_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRLCPY(?![A-Za-z0-9_])/EVENT__HAVE_STRLCPY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRSEP(?![A-Za-z0-9_])/EVENT__HAVE_STRSEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRTOK_R(?![A-Za-z0-9_])/EVENT__HAVE_STRTOK_R/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRTOLL(?![A-Za-z0-9_])/EVENT__HAVE_STRTOLL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_ADDRINFO(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_ADDRINFO/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR_S6_ADDR16(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR_S6_ADDR16/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_IN6_ADDR_S6_ADDR32(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_IN6_ADDR_S6_ADDR32/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN6(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN6/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN6_SIN6_LEN(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN6_SIN6_LEN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_IN_SIN_LEN(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_IN_SIN_LEN/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY(?![A-Za-z0-9_])/EVENT__HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYSCTL(?![A-Za-z0-9_])/EVENT__HAVE_SYSCTL/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_DEVPOLL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_DEVPOLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EPOLL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EPOLL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EVENTFD_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EVENTFD_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_EVENT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_EVENT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_IOCTL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_IOCTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_MMAN_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_MMAN_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_PARAM_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_PARAM_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_QUEUE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_QUEUE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_RESOURCE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_RESOURCE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SELECT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SELECT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SENDFILE_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SENDFILE_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SOCKET_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SOCKET_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_STAT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_STAT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_SYSCTL_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_SYSCTL_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_TIME_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_TIME_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_TYPES_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_TYPES_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_UIO_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_UIO_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_SYS_WAIT_H(?![A-Za-z0-9_])/EVENT__HAVE_SYS_WAIT_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TAILQFOREACH(?![A-Za-z0-9_])/EVENT__HAVE_TAILQFOREACH/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERADD(?![A-Za-z0-9_])/EVENT__HAVE_TIMERADD/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERCLEAR(?![A-Za-z0-9_])/EVENT__HAVE_TIMERCLEAR/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERCMP(?![A-Za-z0-9_])/EVENT__HAVE_TIMERCMP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_TIMERISSET(?![A-Za-z0-9_])/EVENT__HAVE_TIMERISSET/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT16_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT16_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT32_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT32_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT64_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT64_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINT8_T(?![A-Za-z0-9_])/EVENT__HAVE_UINT8_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UINTPTR_T(?![A-Za-z0-9_])/EVENT__HAVE_UINTPTR_T/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UNISTD_H(?![A-Za-z0-9_])/EVENT__HAVE_UNISTD_H/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_UNSETENV(?![A-Za-z0-9_])/EVENT__HAVE_UNSETENV/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_USLEEP(?![A-Za-z0-9_])/EVENT__HAVE_USLEEP/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_VASPRINTF(?![A-Za-z0-9_])/EVENT__HAVE_VASPRINTF/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_WORKING_KQUEUE(?![A-Za-z0-9_])/EVENT__HAVE_WORKING_KQUEUE/g; s/(?<![A-Za-z0-9_])_EVENT_HAVE_ZLIB_H(?![A-Za-z0-9_])/EVENT__HAVE_ZLIB_H/g; s/(?<![A-Za-z0-9_])_EVENT_LT_OBJDIR(?![A-Za-z0-9_])/EVENT__LT_OBJDIR/g; s/(?<![A-Za-z0-9_])_EVENT_NO_MINUS_C_MINUS_O(?![A-Za-z0-9_])/EVENT__NO_MINUS_C_MINUS_O/g; s/(?<![A-Za-z0-9_])_EVENT_NUMERIC_VERSION(?![A-Za-z0-9_])/EVENT__NUMERIC_VERSION/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE(?![A-Za-z0-9_])/EVENT__PACKAGE/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_BUGREPORT(?![A-Za-z0-9_])/EVENT__PACKAGE_BUGREPORT/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_NAME(?![A-Za-z0-9_])/EVENT__PACKAGE_NAME/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_STRING(?![A-Za-z0-9_])/EVENT__PACKAGE_STRING/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_TARNAME(?![A-Za-z0-9_])/EVENT__PACKAGE_TARNAME/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_URL(?![A-Za-z0-9_])/EVENT__PACKAGE_URL/g; s/(?<![A-Za-z0-9_])_EVENT_PACKAGE_VERSION(?![A-Za-z0-9_])/EVENT__PACKAGE_VERSION/g; s/(?<![A-Za-z0-9_])_EVENT_PTHREAD_CREATE_JOINABLE(?![A-Za-z0-9_])/EVENT__PTHREAD_CREATE_JOINABLE/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_INT(?![A-Za-z0-9_])/EVENT__SIZEOF_INT/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_LONG(?![A-Za-z0-9_])/EVENT__SIZEOF_LONG/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_LONG_LONG(?![A-Za-z0-9_])/EVENT__SIZEOF_LONG_LONG/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_OFF_T(?![A-Za-z0-9_])/EVENT__SIZEOF_OFF_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_PTHREAD_T(?![A-Za-z0-9_])/EVENT__SIZEOF_PTHREAD_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_SHORT(?![A-Za-z0-9_])/EVENT__SIZEOF_SHORT/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_SIZE_T(?![A-Za-z0-9_])/EVENT__SIZEOF_SIZE_T/g; s/(?<![A-Za-z0-9_])_EVENT_SIZEOF_VOID_P(?![A-Za-z0-9_])/EVENT__SIZEOF_VOID_P/g; s/(?<![A-Za-z0-9_])_EVENT_STDC_HEADERS(?![A-Za-z0-9_])/EVENT__STDC_HEADERS/g; s/(?<![A-Za-z0-9_])_EVENT_TIME_WITH_SYS_TIME(?![A-Za-z0-9_])/EVENT__TIME_WITH_SYS_TIME/g; s/(?<![A-Za-z0-9_])_EVENT_VERSION(?![A-Za-z0-9_])/EVENT__VERSION/g; s/(?<![A-Za-z0-9_])_EVENT__ALL_SOURCE(?![A-Za-z0-9_])/EVENT___ALL_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__FILE_OFFSET_BITS(?![A-Za-z0-9_])/EVENT___FILE_OFFSET_BITS/g; s/(?<![A-Za-z0-9_])_EVENT__GNU_SOURCE(?![A-Za-z0-9_])/EVENT___GNU_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__LARGE_FILES(?![A-Za-z0-9_])/EVENT___LARGE_FILES/g; s/(?<![A-Za-z0-9_])_EVENT__MINIX(?![A-Za-z0-9_])/EVENT___MINIX/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_1_SOURCE(?![A-Za-z0-9_])/EVENT___POSIX_1_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_PTHREAD_SEMANTICS(?![A-Za-z0-9_])/EVENT___POSIX_PTHREAD_SEMANTICS/g; s/(?<![A-Za-z0-9_])_EVENT__POSIX_SOURCE(?![A-Za-z0-9_])/EVENT___POSIX_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT__TANDEM_SOURCE(?![A-Za-z0-9_])/EVENT___TANDEM_SOURCE/g; s/(?<![A-Za-z0-9_])_EVENT___EXTENSIONS__(?![A-Za-z0-9_])/EVENT____EXTENSIONS__/g; s/(?<![A-Za-z0-9_])_EVENT___func__(?![A-Za-z0-9_])/EVENT____func__/g; s/(?<![A-Za-z0-9_])_EVENT_const(?![A-Za-z0-9_])/EVENT__const/g; s/(?<![A-Za-z0-9_])_EVENT_inline(?![A-Za-z0-9_])/EVENT__inline/g; s/(?<![A-Za-z0-9_])_EVENT_pid_t(?![A-Za-z0-9_])/EVENT__pid_t/g; s/(?<![A-Za-z0-9_])_EVENT_size_t(?![A-Za-z0-9_])/EVENT__size_t/g; s/(?<![A-Za-z0-9_])_EVENT_socklen_t(?![A-Za-z0-9_])/EVENT__socklen_t/g; s/(?<![A-Za-z0-9_])_EVENT_ssize_t(?![A-Za-z0-9_])/EVENT__ssize_t/g;
2012-02-29 15:07:31 -05:00
#ifdef EVENT__HAVE_SYS_SOCKET_H
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
#include <sys/socket.h>
#endif
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include "event2/event.h"
#include "event2/util.h"
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
#include <time.h>
struct cpu_usage_timer {
#ifdef _WIN32
HANDLE thread;
FILETIME usertimeBegin;
FILETIME kerneltimeBegin;
#else
clock_t ticksBegin;
#endif
struct timeval timeBegin;
};
static void
start_cpu_usage_timer(struct cpu_usage_timer *timer)
{
#ifdef _WIN32
int r;
FILETIME createtime, exittime;
timer->thread = GetCurrentThread();
r = GetThreadTimes(timer->thread, &createtime, &exittime,
&timer->usertimeBegin, &timer->kerneltimeBegin);
if (r==0) printf("GetThreadTimes failed.");
#else
timer->ticksBegin = clock();
#endif
evutil_gettimeofday(&timer->timeBegin, NULL);
}
#ifdef _WIN32
static ev_int64_t
filetime_to_100nsec(const FILETIME *ft)
{
/* Number of 100-nanosecond units */
ev_int64_t n = ft->dwHighDateTime;
n <<= 32;
n += ft->dwLowDateTime;
return n;
}
static double
filetime_diff(const FILETIME *ftStart, const FILETIME *ftEnd)
{
ev_int64_t s, e, diff;
double r;
s = filetime_to_100nsec(ftStart);
e = filetime_to_100nsec(ftEnd);
diff = e - s;
r = (double) diff;
return r / 1.0e7;
}
#endif
static void
get_cpu_usage(struct cpu_usage_timer *timer, double *secElapsedOut,
double *secUsedOut, double *usageOut)
{
#ifdef _WIN32
double usertime_seconds, kerneltime_seconds;
FILETIME createtime, exittime, usertimeEnd, kerneltimeEnd;
int r;
#else
clock_t ticksEnd;
#endif
struct timeval timeEnd, timeDiff;
double secondsPassed, secondsUsed;
#ifdef _WIN32
r = GetThreadTimes(timer->thread, &createtime, &exittime,
&usertimeEnd, &kerneltimeEnd);
if (r==0) printf("GetThreadTimes failed.");
usertime_seconds = filetime_diff(&timer->usertimeBegin, &usertimeEnd);
kerneltime_seconds = filetime_diff(&timer->kerneltimeBegin, &kerneltimeEnd);
secondsUsed = kerneltime_seconds + usertime_seconds;
#else
ticksEnd = clock();
secondsUsed = (ticksEnd - timer->ticksBegin) / (double)CLOCKS_PER_SEC;
#endif
evutil_gettimeofday(&timeEnd, NULL);
evutil_timersub(&timeEnd, &timer->timeBegin, &timeDiff);
secondsPassed = timeDiff.tv_sec + (timeDiff.tv_usec / 1.0e6);
*secElapsedOut = secondsPassed;
*secUsedOut = secondsUsed;
*usageOut = secondsUsed / secondsPassed;
}
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
static void
write_cb(evutil_socket_t fd, short event, void *arg)
2010-07-19 15:03:43 +02:00
{
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
printf("write callback. should only see this once\n");
2010-07-19 15:03:43 +02:00
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
/* got what we want remove the event */
event_del(*(struct event**)arg);
/* opps changed my mind add it back again */
event_add(*(struct event**)arg,NULL);
/* not a good day for decisiveness, I really didn't want it after all */
event_del(*(struct event**)arg);
}
static void
timeout_cb(evutil_socket_t fd, short event, void *arg)
2010-07-19 15:03:43 +02:00
{
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
printf("timeout fired, time to end test\n");
event_del(*(struct event**)arg);
return;
}
int
main(int argc, char **argv)
{
struct event* ev;
struct event* timeout;
struct event_base* base;
2010-11-03 14:38:45 -07:00
evutil_socket_t pair[2];
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
struct timeval tv;
struct cpu_usage_timer timer;
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
double usage, secPassed, secUsed;
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
#ifdef _WIN32
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
WORD wVersionRequested;
WSADATA wsaData;
wVersionRequested = MAKEWORD(2, 2);
(void) WSAStartup(wVersionRequested, &wsaData);
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
#endif
if (evutil_socketpair(AF_UNIX, SOCK_STREAM, 0, pair) == -1)
return (1);
/* Initialize the event library */
if (!(base = event_base_new()))
return (1);
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
/* Initialize a timeout to terminate the test */
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
timeout = evtimer_new(base,timeout_cb,&timeout);
if (timeout == NULL)
return (1);
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
/* and watch for writability on one end of the pipe */
ev = event_new(base,pair[1],EV_WRITE | EV_PERSIST, write_cb, &ev);
if (ev == NULL)
return (1);
2012-01-27 15:10:28 -05:00
tv.tv_sec = 1;
tv.tv_usec = 500*1000;
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
evtimer_add(timeout, &tv);
event_add(ev, NULL);
start_cpu_usage_timer(&timer);
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
event_base_dispatch(base);
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
event_free(ev);
event_free(timeout);
event_base_free(base);
get_cpu_usage(&timer, &secPassed, &secUsed, &usage);
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
/* attempt to calculate our cpu usage over the test should be
virtually nil */
2010-07-19 15:03:43 +02:00
printf("usec used=%d, usec passed=%d, cpu usage=%.2f%%\n",
(int)(secUsed*1e6),
(int)(secPassed*1e6),
usage*100);
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
if (usage > 50.0) /* way too high */
return 1;
return 0;
}