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()
We should use the recently added
Lighthouse::closemethod1 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):lighthouse-rust/lighthouse-client/src/lighthouse.rs
Lines 303 to 308 in 87d7b14
Depending on the type of application, there seem to be two reasonable approaches here:
examples/black.rs), simply call (and await).close()at the end of the scriptlimo) we could likely do the same, but would make sure that ctrl-d properly goes down this code path.close()Footnotes
Unfortunately we cannot just put this method into a
Dropimplementation 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. ↩