-
Notifications
You must be signed in to change notification settings - Fork 751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eliminate busy loop when receiving messages from non-blocking socket #977
base: main
Are you sure you want to change the base?
Conversation
For a non-blocking socket, it should wait for events first before receiving messages from the socket, otherwise it would receive empty message and run into a busy loop. Signed-off-by: Quan Tian <[email protected]>
@@ -75,7 +75,7 @@ func TestIfSocketCloses(t *testing.T) { | |||
for { | |||
_, _, err := sk.Receive() | |||
// Receive returned because of a timeout and the FD == -1 means that the socket got closed | |||
if err == unix.EAGAIN && nlSock.GetFd() == -1 { | |||
if nlSock.GetFd() == -1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The err is no longer unix.EAGAIN
because Receive
doesn't return when blocking on unix.Recvfrom
, instead, it blocks on unix.Poll
, then after 2s timeout, it calls unix.Recvfrom
and gets "bad file descriptor"
@tnqn please resolve the conflicts |
Thanks for reminding, will do. |
@tnqn ping |
@aboch sorry for the late response. I'm trying to verify my change does resolve the issue described in #941, which is why it changed @kuroa-me could you help me understand how to reproduce the issue? Do you have a reproducer that I can use to validate my change? The following is the code I used to test, but it has never failed even with 1000 IPs added or deleted in batch.
|
Hmm, interesting. Please give me some time on trying to reproduce this, I could not find my old test suits. But I do remember that this relates to SLAAC when the interface is being |
Most intriguing, SLAAC does not affect netlink from acquring LLA. I will keep seeking what is missing... Edit: I looked this issue at when investigating the problem back in January. sonic-net/sonic-swss-common#114 Should we put in the non-blocking for good measure? I will keep trying to reproduce the issue in the meanwhile. |
For a non-blocking socket, it should wait for events first before receiving messages from the socket, otherwise it would receive empty message and run into a busy loop.
This is an alternative of #976.
Fixes #975