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

Close Lighthouse properly in examples #17

Open
fwcd opened this issue Jul 17, 2024 · 0 comments
Open

Close Lighthouse properly in examples #17

fwcd opened this issue Jul 17, 2024 · 0 comments

Comments

@fwcd
Copy link
Member

fwcd commented Jul 17, 2024

We should use the recently added Lighthouse::close method1 in the examples to avoid closing the WebSocket without sending the close handshake (while not critical, it seems to be good practice to do so):

/// Closes the WebSocket connection gracefully with a close message. While
/// the server will usually also handle abruptly closed connections
/// properly, it is recommended to always close the [``Lighthouse``].
pub async fn close(&mut self) -> Result<()> {
Ok(self.ws_sink.close().await?)
}

Depending on the type of application, there seem to be two reasonable approaches here:

  • For one-shot scripts (e.g. examples/black.rs), simply call (and await) .close() at the end of the script
  • For REPLs (e.g. limo) we could likely do the same, but would make sure that ctrl-d properly goes down this code path
  • For continuously running applications (e.g. games), set up a signal handler (e.g. await Tokio's ctrl-c) and then call .close()

Footnotes

  1. Unfortunately we cannot just put this method into a Drop implementation due to being async and error-throwing. We could look into spawning a task in the drop handler, but that would no longer let us await the close, which could lead to subtle/hard-to-debug race conditions.

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

1 participant