The base should be notified in case of timer removal if that was the
minimal timer in the base.
Reported-by: @moihn (who is also provided the reproducer on which this
test is based on)
Fixes: https://github.com/libevent/libevent/issues/1727
Register the eventfd with EPOLLET to enable edge-triggered notification
where we don't need to read the data from the eventfd for every wakeup
event.
When the eventfd counter reaches the maximum value of the unsigned 64-bit,
we rewind the counter and retry again. This optimization saves one system
call on each event-loop wakeup, which eliminates the extra latency for epoll
as the EVFILT_USER filter does for the kqueue.
The benefit of this optimization is questionable for the following
reasons:
- libevent uses CLOCK_MONOTONIC_COARSE which is fast enough (on my
desktop CLOCK_MONOTONIC/CLOCK_MONOTONIC_RAW works 40/50 millions of
ops per second, and CLOCK_MONOTONIC_COARSE is faster)
- libevent has caching of time (EVENT_BASE_FLAG_NO_CACHE_TIME)
So I don't see any reason for using one more caching - lazy comparsion
(whatever you call it).
For the CMake release build with -DEVENT__ENABLE_GCC_WARNINGS=ON
and -DEVENT__DISABLE_MM_REPLACEMENT=ON, GCC version 11 and 12 may
complain about possibly uninitialized variable:
In function ‘event_debug_assert_not_added_’,
inlined from ‘event_assign’ at event.c:2184:2,
inlined from ‘event_new’ at event.c:2276:6:
cc1: error: ‘ev’ may be used uninitialized [-Werror=maybe-uninitialized]
event.c: In function ‘event_new’:
event.c:361:13: note: by argument 1 of type ‘const struct event *’ to event_debug_assert_not_added_.part.0’ declared here
361 | static void event_debug_assert_not_added_(const struct event *ev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This warning is most likely a false positive and can be silenced
by explicitly disabling inlining for 'event_assign()'.
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
Linux-specific signal handling backend based on signalfd(2)
system call, and public function event_base_get_signal_method()
to obtain an underlying kernel signal handling mechanism.
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
gcc 12 complains:
[34/46] Building C object CMakeFiles/event_static.dir/event.c.o
/src/le/libevent/event.c: In function ‘event_signal_closure’:
/src/le/libevent/event.c:1384:32: warning: storing the address of local variable ‘ncalls’ in ‘*ev.ev_.ev_signal.ev_pncalls’ [-Wdangling-pointer=]
1384 | ev->ev_pncalls = &ncalls;
| ~~~~~~~~~~~~~~~^~~~~~~~~
/src/le/libevent/event.c:1378:15: note: ‘ncalls’ declared here
1378 | short ncalls;
| ^~~~~~
/src/le/libevent/event.c:1378:15: note: ‘ev’ declared here
libevent is lacking a scalable backend on Windows. Let's leverage the wepoll
library until Windows comes up with an epoll/kqueue compete user mode API.
- All regress tests pass for standard wepoll
- These 2 tests fail intermittently for changelist wepoll, so disabling
changelist wepoll for now
http/cancel_inactive_server
http/stream_in
- verify target on Windows runs tests for both wepoll and win32 backends
- wepoll backend preferred over win32 backend
- wepoll version 1.5.6
v2: cleaner backend abstraction. Disallow wepoll on MinGW/Cygwin.
v3: Add wepoll.h to dist
v4: Make sure wepoll source files are excluded from cygwin/mingw builds
v5: Keep win32 as default backend on windows.
v6: Include wepoll in mingw builds. Verified that regress tests pass w/ WEPOLL backend.
v7: Enable wepoll on mingw when building with cmake
v8: Add wepoll testrunner for autotools test target
supposing if base is null, EVBASE_ACQUIRE_LOCK and EVBASE_RELEASE_LOCK
would get a coredump, so we add a guard for protection.
Signed-off-by: chenguolong <cgl.chenguolong@huawei.com>
Calling fork() from the event loop is not a great idea, since at least
it shares some internal pipes (for handling signals) before
event_reinit() call
Closes: #833
Converting unsigned to size_t for size of memory objects allows
proper handling of very large heaps on 64 bit systems.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Closes: #799 (cherry-picked)
There was a race between event_base_loop and evwatch_new (adding a
prepare/check watcher while iterating over the watcher list). Only
release the mutex immediately before invoking each watcher callback,
and reacquire it immediately afterwards (same as is done for normal
event handlers).
Adds two new callbacks: "prepare" watchers, which fire immediately
before we poll for I/O, and "check" watchers, which fire immediately
after we finish polling and before we process events. This allows other
event loops to be embedded into libevent's, and enables certain
performance monitoring.
Closes: #710
Check that each fd that had been added with some event do has O_NOBLOCK
after event_enable_debug_mode()
Rebased and do not check signals (EV_SIGNAL) by azat.
Refs: nmathewson/Libevent#90
Refs: #96
Image next situation:
T1: T2:
event_del_()
lock the event.ev_base.th_base_lock
event_del_nolock_() event_set_base()
unlock the event.ev_base.th_base_lock
In this case we will unlock the wrong base after event_del_nolock_()
returns, and deadlock is likely to happens, since event_base_set() do
not check any mutexes (due to it is possible to do this only if event is
not inserted anywhere).
So event_del_() has to cache the base before removing the event, and
cached base.th_base_lock after.
Detected using ThreadSanitizer, resolved by capturing the value
of ev_res in a local variable while the event is locked, then
passing that captured variable to the callback.
TSAN report:
I0728 14:35:09.822118 WARNING: ThreadSanitizer: data race (pid=815501)
I0728 14:35:09.822186 Write of size 2 at 0x7b2c00001bf2 by thread T80 (mutexes: write M1110835549570434736):
I0728 14:35:09.822248 #0 event_active_nolock_ libevent/event.c:2893:14 (0a2b90577e830d775300664df77d0b91+0x1fdab28)
I0728 14:35:09.822316 #1 event_active libevent/event.c:2858:2 (0a2b90577e830d775300664df77d0b91+0x1fdd10e)
I0728 14:35:09.822379 #2 Envoy::Event::TimerImpl::enableTimer(std::chrono::duration<long, std::ratio<1l, 1000l> > const&) envoy/source/common/event/timer_impl.cc:24:5 (0a2b90577e830d775300664df77d0b91+0x459fa0)
...
I0728 14:35:09.824146 Previous read of size 2 at 0x7b2c00001bf2 by main thread:
I0728 14:35:09.824232 #0 event_process_active_single_queue libevent/event.c:1646:33 (0a2b90577e830d775300664df77d0b91+0x1fdf83d)
I0728 14:35:09.824350 #1 event_process_active libevent/event.c (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824445 #2 event_base_loop libevent/event.c:1961 (0a2b90577e830d775300664df77d0b91+0x1fd9ad8)
I0728 14:35:09.824550 #3 Envoy::Event::DispatcherImpl::run(Envoy::Event::Dispatcher::RunType) envoy/source/common/event/dispatcher_impl.cc:166:3 (0a2b90577e830d775300664df77d0b91+0x4576d9)
...
Fixes: #543 (pull-request)
Delete the event from the queue before blocking for the current
event callback termination.
Ensures that no callback is being executed when event_del() returns,
hence making this function a secure mechanism to access data which is
handled in the event callack.
Fixes: #236Fixes: #225
Refs: 6b4b77a
Fixes: del_wait
event_reinit() removes the event, but only evsig_add puts it back. So any
signals set up before event_reinit will be ignored until another signal is
added.
Fixes: #307
Before this patch event_reinit() only closes the signal socketpair fds and
recreates them if signals have been added, but this is wrong, since socketpair
fds created on backend init, and if we will not re-create them bad things in
child/parent signal handling will happens (and indeed this is what happens for
non-reinit backends like select).
Fixes: #307
For finalizers we can register yet another finalizer out from finalizer, and
iff finalizer will be in active_later_queue we can add finalizer to
activequeues, and we will have events in activequeues after event_base_free()
returns, which is not what we want (we even have an assertion for this).
A simple case is bufferevent with underlying (i.e. filters) in inactive queue.
Fixes: regress bufferevent/bufferevent_socket_filter_inactive
The following command failed before:
$ ./configure --disable-debug-mode
Fixes: dcfb19a27b7760299bc9e7291c9abd88c59fd91a ("Debug mode option to error on
evthread init AFTER other event calls.")
- A handy event_enable_debug_mode() feature which will error and abort the
application if any thread-aware libevent functions are called BEFORE the
evthread API has been initialized (manually, or through
evthread_use_windows_threads() / evthread_use_pthreads()
- This is done by setting the global debug variable
'event_debug_created_threadable_ctx_' whenever the following functions
are called:
evthreadimpl_lock_alloc_()
evthreadimpl_cond_alloc_()
event_base_new_with_config() <- this checks to see if the thread
callbacks are enabled first, so we
have to manually set the variable.
- Example:
int main(int argc, char ** argv) {
struct event_base * base;
event_enable_debug_mode();
base = event_base_new();
evthread_use_pthreads();
return 0;
}
When executed, the program will throw an error and exit:
[err] evthread initialization must be called BEFORE anything else!
This will avoid leaking of event_debug_map_HT_GROW
I buildin it into libevent_glboal_shutdown() because
event_disable_debug_mode() -> event_free_debug_globals() ->
event_free_debug_globals_locks() will clean event_debug_map_lock_ that
used in event_disable_debug_mode().
