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

Additional docs for hanging sockets & shared futures/promises #2030

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

arkocetu
Copy link

@arkocetu arkocetu commented Jan 4, 2024

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.

Added documentation for how to use shared_future/shared_promise
@arkocetu arkocetu closed this Jan 4, 2024
@arkocetu arkocetu reopened this Jan 4, 2024
@arkocetu arkocetu changed the title Added documentation for procedure to close a hanging socket Additional docs for hanging sockets & shared futures/promises Jan 4, 2024
```
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
Copy link
Member

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added note about this.

Comment on lines 60 to 61
});
});
Copy link
Member

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.

Copy link
Author

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.

}).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
Copy link
Member

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.

Copy link
Author

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

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

Successfully merging this pull request may close these issues.

None yet

2 participants