core: Use eventfd for alert pipes on Linux when possible
authorSean Bright <sean.bright@gmail.com>
Tue, 18 Apr 2017 00:06:10 +0000 (20:06 -0400)
committerSean Bright <sean.bright@gmail.com>
Mon, 24 Apr 2017 16:50:09 +0000 (11:50 -0500)
commit59203c51cc6a9676ef1ab42aebe070a55f55ead2
tree474f8136a9a10ee4720c58e4a9d9dc2b6015f03a
parentdc6654d969224129bdd7b4080eda6e027c6454b9
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
configure
configure.ac
include/asterisk/alertpipe.h [new file with mode: 0644]
include/asterisk/autoconfig.h.in
include/asterisk/channel.h
main/alertpipe.c [new file with mode: 0644]
main/bridge_channel.c
main/channel_internal_api.c
main/utils.c