From 59203c51cc6a9676ef1ab42aebe070a55f55ead2 Mon Sep 17 00:00:00 2001 From: Sean Bright Date: Mon, 17 Apr 2017 20:06:10 -0400 Subject: core: Use eventfd for alert pipes on Linux when possible The primary win of switching to eventfd when possible is that it only uses a single file descriptor while pipe() will use two. This means for each bridge channel we're reducing the number of required file descriptors by 1, and - if you're using timerfd - we also now have 1 less file descriptor per Asterisk channel. The API is not ideal (passing int arrays), but this is the cleanest approach I could come up with to maintain API/ABI. I've also removed what I believe to be an erroneous code block that checked the non-blocking flag on the pipe ends for each read. If the file descriptor is 'losing' its non-blocking mode, it is because of a bug somewhere else in our code. In my testing I haven't seen any measurable difference in performance. Change-Id: Iff0fb1573e7f7a187d5211ddc60aa8f3da3edb1d --- include/asterisk/autoconfig.h.in | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'include/asterisk/autoconfig.h.in') diff --git a/include/asterisk/autoconfig.h.in b/include/asterisk/autoconfig.h.in index 5f8a9d37c..b39386b43 100644 --- a/include/asterisk/autoconfig.h.in +++ b/include/asterisk/autoconfig.h.in @@ -225,6 +225,10 @@ /* Define to 1 if you have the `euidaccess' function. */ #undef HAVE_EUIDACCESS +/* Define to 1 if your system supports eventfd and the EFD_NONBLOCK and + EFD_SEMAPHORE flags. */ +#undef HAVE_EVENTFD + /* Define to 1 if you have the `exp' function. */ #undef HAVE_EXP -- cgit v1.2.3