-
Notifications
You must be signed in to change notification settings - Fork 9
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
Busy loop when client is connected #12
Comments
Logs from the server: during connect:
During disconnect (^C on the client):
I think the problem is the wakeup from Writable, even if no data is about to be written (?). |
The zero timeout in the event loop thread is there to minimize latency. And that means one core is busy spinning all the time. One way to fix it is to let the user configure the timeout in the session options. Another one is to have the endpoint state machine register to the writable event only when required, this is clearly more difficult and risky. |
1 similar comment
The zero timeout in the event loop thread is there to minimize latency. And that means one core is busy spinning all the time. One way to fix it is to let the user configure the timeout in the session options. Another one is to have the endpoint state machine register to the writable event only when required, this is clearly more difficult and risky. |
Considering the additional loglines and skipping through some mio docs I'm guessing it's explicitly requesting to be notified when the socket can be written, ie. the kernel write buffer has capacity. Since this is usually always the case for idle connections, epoll_wait returns instantly. I agree that the correct way would be deregistering on write notifications. I'd argue that having a syscall return as soon as something needs to be done should have at least equal latency as constantly polling if something needs to be done. ;) Having the process run on zero instructions on idle would also potentionally reduce wear on low-power hardware like raspberry pis. It seems |
I remember having started with This is because of this kind of problems that I think it would be better to rely on tokio rather than mio. |
I see the same problem in my app: 100% all the time even if it is waiting for timeout. Disabled message sending and 0%. Could you please recommend: is better to migrate to nanomsg.rs or wait for fix? Thank you, |
If you need something that actually works, it really is a better idea to use nanomsg.rs. It is a rust wrapper around the original C library so one can be much more confident. I don't see a fix happening in the near future. |
I've noticed that, if a client connects to the server, both the server and the client enter a busy loop until one of them disconnects. Both of them call epoll_pwait as fast as possible until data is returned. I assume there is a timeout of 0 somewhere that shouldn't be there.
The text was updated successfully, but these errors were encountered: