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
Given the outcome of #23194, there is currently no way within rust to cleanly terminate a UDP receive loop thread. If shutdown() is not possible, the only other option I see is to expose a recv_from_timeout of some sort on UdpSocket, so that the thread can periodically check whether a message has been sent on a channel, and terminate when such a message is received.
After thinking about this briefly, I suppose it is possible to craft a special UDP packet and send it to the locally bound UDP port, and have the receive thread terminate when it receives that special packet. I don't think this is necessarily a good way to force people to cleanly terminate such a loop, but it is an option right now.
The text was updated successfully, but these errors were encountered:
In general this starts breaching into the async I/O territory as what you probably "really want to do" is wait on some form of pipe plus a UDP socket and then send something on the pipe to have the call be unblocked. It looks like the OS-provided shutdown isn't always what we want, so there's no direct analog for supporting this, and as such it would require quite a bit of extra infrastructure.
As a result, I'm going to close this and add its use case to rust-lang/rfcs#957 instead. Thanks for the issue though!
Given the outcome of #23194, there is currently no way within rust to cleanly terminate a UDP receive loop thread. If shutdown() is not possible, the only other option I see is to expose a recv_from_timeout of some sort on UdpSocket, so that the thread can periodically check whether a message has been sent on a channel, and terminate when such a message is received.
After thinking about this briefly, I suppose it is possible to craft a special UDP packet and send it to the locally bound UDP port, and have the receive thread terminate when it receives that special packet. I don't think this is necessarily a good way to force people to cleanly terminate such a loop, but it is an option right now.
The text was updated successfully, but these errors were encountered: