Skip to content
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

[bug] connection can not be recycled if there is no multicast message from kernel. #15

Open
abel-von opened this issue Mar 30, 2023 · 1 comment

Comments

@abel-von
Copy link

Hi, we are using rtnetlink to find the links and routes, we need to create the handle repeatly because we have to do manipulate many network namespaces.

we have encountered an issue that the Connection which is created by new_connection can not be recycled when the 'Handle' is already dropped. after we call tokio::spawn(connection), the connection is inside tokio runtime and can not be dropped because it do not return Poll::Ready.

we checked the codes and found that it is because the unsolicited_message_tx has to be taken to none so that the should_shut_down can return true, but if there is no milticast message from the kernel to the socket, there is no chance that the unsolicited_message_tx be take to None.

image

maybe we can expose an API like new_connection_without_messages. and let unsolicited_message_tx to None if users do not care the multicast message. or maybe there are some other resolutions?

@koalo
Copy link

koalo commented May 11, 2023

I just ran into the same problem and I am surprised that this is not a more common, especially for long running processes/daemons instead of CLI tools.
Thank you for the detailed analysis!
It is possible to fix this without API change by just explicitly checking if the channel is closed in addition to checking for ready. See rust-netlink/netlink-proto#10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants