-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Additional docs for hanging sockets & shared futures/promises #2030
base: master
Are you sure you want to change the base?
Conversation
Added documentation for how to use shared_future/shared_promise
doc/hanging-socket.md
Outdated
``` | ||
In this example, the next step after read, will never happen, and we'll never reach the "end" state. | ||
|
||
A simple solution for this case might be to add a timeout on the read operation, in the case the client doesn't do any progress, for instance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please mention that it's wrong up-front, before people (or copilot) starts copy'n'pasting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added note about this.
doc/hanging-socket.md
Outdated
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to rewrite the examples are coroutines, nobody should be using continuations in 2024.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All examples are written with coroutine.
doc/hanging-socket.md
Outdated
}).handle_exception_type([&s] (const seastar::timed_out_error &err) { | ||
// Will resolve the currently waiting futures, with an exception | ||
s.shutdown_input(); | ||
// Allows to wait untill the inputs are actually closed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well this is also wrong, since the original continuation escapes. Maybe it works for the example, but for the general case, it's problematic.
The correct approach is to have a separate monitoring fiber issue the shutdown when it wants. Then the original write() just terminates with an exception. It's also more efficient as we don't wrap everything with with_timeout wrappers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What can be a good approach for such handling, for example, if we set operation counter, and in the monitor fiber, we just verify that the counter changing in between a specified timeout for example?
Because otherwise I don't see a way to see if the socket is actually making any progress.
Or maybe you can suggest a better approach? If possible
The docs currently lacking some explanation how to deal with clients/servers that don't send any data, and how to close them correctly.
Added additional explanation about shared futures/promises which aren't documented under the tutorial, and only can be found in the reference.