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

No way to cleanly terminate a dedicated UDP receive thread #23272

Closed
LorenVS opened this issue Mar 11, 2015 · 1 comment
Closed

No way to cleanly terminate a dedicated UDP receive thread #23272

LorenVS opened this issue Mar 11, 2015 · 1 comment

Comments

@LorenVS
Copy link

LorenVS commented Mar 11, 2015

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.

@alexcrichton
Copy link
Member

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!

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