-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Add checks in from_std to ensure that it is non-blocking #3539
Comments
This is a big deal. I spent several hours debugging the issue. I can reproduce it with this minimal example:
In this example, read does not happen, it hangs in accept. (Edit: fixed explanation of what was going on.) But for simpler example, without
So this is very easy mistake to make and very hard to debug. We should
|
Thanks for reporting this. I am assigning @Darksonn to put together a proposal. |
I bumped into this today and spent the whole afternoon (instead of meeting cool folks at FOSDEM) to figure out why my tasks don't spawn.
@Darksonn polite reminder. :) I think the solution here is simple: since I can provide a PR for this. |
The problem is not making the PR — it is coming to a decision about which of the options is best. In fact, there's already a PR: #5597. |
Gotcha! Given that it's a pretty bad footgun that wastes people's time and that
Cool. That's pretty complicated and seem to suggest new/breaking API though. I don't really see the use case of having user set the non-blocking mode themselves since tokio requires that. My suggestion above is simple and wouldn't require API break in most cases. The only hurdle I bumped into while trying to write the PR was that some of the |
I think, from the docs on What we could consider doing is:
If we find anybody who still has a legitimate case for passing in a blocking socket, we can consider adding a specific API for that that bypasses the debug assertion. |
I don't think anyone was asserting there is a use case for this. The problem is that since the non-blocking setting is not reflected in the type, people can make mistakes and end up wasting hours debugging this. A runtime assertion would help for sure but still not so nice. What would be a more interesting question, is if there is a good reason tokio can't do this for the user? Given user gives up the ownership of the socket in question, I don't see why tokio can't set any settings on it, that it needs. |
That could be a reasonable choice if we designed the API today, but I'm concerned about breaking changes. It also introduces a runtime cost, because most sockets passed to There have been ideas such as deprecating |
That's fair.
Is that a significant enough cost to care about? 🤔 This is not an objection. I'm genuinely curious.
If you want to not break the API, then those options sound good to me. |
Is your feature request related to a problem? Please describe.
Multiple users (including me) have fallen in to this trap. Getting a
UdpSocket
from some other libraries and forget to set it as non-blocking can hang the runtime in a way that is not easy to debug (especially for beginners).Describe the solution you'd like
Some checks that ensures that the socket being passed in is indeed non-blocking. This is doable in Linux with
fnctl
, but I'm not sure about the status on Windows.Such check can be designed so that it only preforms in debug mode, as extra syscalls are usually involved.
Ideally, this should trigger a panic if the check fails, but an error is better than nothing.
The text was updated successfully, but these errors were encountered: