-
- Downloads
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
Showing
- configure 35 additions, 0 deletionsconfigure
- configure.ac 9 additions, 0 deletionsconfigure.ac
- include/asterisk/alertpipe.h 159 additions, 0 deletionsinclude/asterisk/alertpipe.h
- include/asterisk/autoconfig.h.in 4 additions, 0 deletionsinclude/asterisk/autoconfig.h.in
- include/asterisk/channel.h 1 addition, 6 deletionsinclude/asterisk/channel.h
- main/alertpipe.c 166 additions, 0 deletionsmain/alertpipe.c
- main/bridge_channel.c 6 additions, 81 deletionsmain/bridge_channel.c
- main/channel_internal_api.c 11 additions, 110 deletionsmain/channel_internal_api.c
- main/utils.c 3 additions, 0 deletionsmain/utils.c
Loading
Please register or sign in to comment