Skip to content
Snippets Groups Projects
  • Sean Bright's avatar
    59203c51
    core: Use eventfd for alert pipes on Linux when possible · 59203c51
    Sean Bright authored
    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
    59203c51
    History
    core: Use eventfd for alert pipes on Linux when possible
    Sean Bright authored
    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