Fix CPU spike caused by hanging connection after socket closure (#8806)

[goktug97]

After the RerunServer shuts down, the broadcast_thread_func in crates/store/re_ws_comms/src/server.rs could not terminate due to the log_rx.recv function entering an infinite loop while attempting to receive data.

To resolve this, recv has been replaced with recv_timeout, allowing the thread to properly shut down and preventing excessive CPU usage.

Related

• Closes serve_web followed by disconnect outside of main thread causes 100% CPU usage #8806

[github-actions]

Hi! Thanks for opening this pull request.

Because this is your first time contributing to this repository, make sure you've read our Contributor Guide and Code of Conduct.

[Wumpf]

thanks for the contribution! However, I don't think that's the correct fix: Instead of making broadcast_thread_func a "slow busyloop", stop_listener should wakeup the broadcast thread by hanging up the ReceiveSet after setting the shutdown flag. ReceiveSet::recv method is documented to return if the set is empty, so calling clear on it after setting the shutdown flag should hopefully do it.

Edit: clear won't work, that just gets stuck in a lock. Needs some more prodding on how a ReceiveSet can be woken up, might be that we need to send a poisoned message of sort

[Wumpf]

log_rx.recv function entering an infinite loop while attempting to receive data.

That actually also sounds a bug in ReceiveSet then - I'd expect it at most to block indefinitely rather than busy-looping

[goktug97]

Makes sense, I checked the ReceiveSet and issue is happening because is_empty() check is done on Vec<Receiver>, not on the Receiver itself. Will revert the previous changes and push the fix.

EDIT: On second look, that might not be the desired behavior

[goktug97]

The issue was due to these lines;

if let Ok(msg) = oper.recv(&rx[index].rx) {
    return Ok(msg);
}

It starts returning RecvError after disconnecting but that branch is not handled so loop enters infinite loop. Latest push solves the problem and serve_web works expected.

[Wumpf]

great catch, thank you so much. I agree, that makes more sense now

[Wumpf]

Hmm strange, not seeing a report from the Rust CI. Maybe something is slightly broken in the gh workflows for non-maintainer contributions. Ah well, main will run it as well and I'm feeling confident enough