Please sign in to comment.
Fix incredibly slim race for maxconns handler
I am an idiot: inbetween setting allow_new_conns -> false and calling the maxconns subroutine, another thread could have already flipped it back. This is probably due to a lack of strict memory barriers allowing the assignments to the allow_new_conns variable to be reordered outside of the lock. Instead of copy/pasting the handler enabler code, we now treat an fd argument of -42 as special and force the callback to run once. Normally fd is -1 since there's no associated socket for the callback.
- Loading branch information...