Changed polling behaviour to speed up response time #11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…socket_service(), speeding up polling
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit changes the polling behaviour to exploit the blocking behaviour of
libwebsocket_service().This means:
libwebsocket_service()is called with a very long timeout, which will block until the callback is called. After the callback has been executed, the dispatch timer will fire immediately againIn some small tests, I could see a large improvement of round-trip-time, in particular when lots of small messages are received in rapid succession (up to 50% less RTT). There seems to be no increase in CPU usage. The only downside I can think of is that the networkQueue is blocked, which shouldn't matter as its only purpose is to wait for an event and execute the callback.
Note that such an approach is also mentioned in the API description of
libwebsocket_service:"Alternatively you can fork a new process that asynchronously handles calling this service in a loop. In that case you are happy if this call blocks your thread until it needs to take care of something and would call it with a large nonzero timeout. Your loop then takes no CPU while there is nothing happening." (https://libwebsockets.org/libwebsockets-api-doc.html)