You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
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
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 bynew_connection
can not be recycled when the 'Handle' is already dropped. after we calltokio::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 theshould_shut_down
can return true, but if there is no milticast message from the kernel to the socket, there is no chance that theunsolicited_message_tx
be take to None.maybe we can expose an API like
new_connection_without_messages
. and letunsolicited_message_tx
to None if users do not care the multicast message. or maybe there are some other resolutions?The text was updated successfully, but these errors were encountered: