Look into running received message events on a separate thread #64

Closed
opened 6 months ago by kimimaru · 2 comments
Owner

Parsing inputs can take a while in the TRBot.Main application after receiving a message, especially when factoring in everything that must be done, including running commands and the extensive post-processing.

At least in the case of the Terminal and Twitch client services, the event loop sending message and command events are already run on their own threads. If two messages come in concurrently, it can't help but wait to completely finish processing one of them before moving onto the next.

Consider moving all the code in BotProgram.OnUserSentMessage into a new thread and starting up this thread from the ThreadPool. This should make TRBot more responsive in popular streams and/or slower machines, and more efficiently utilize resources.

However, keep in mind potential consequences. I forsee an issue with reloading data while it's parsing inputs or running commands. Since the ReloadCommand currently runs on the same thread as the input parsing, there's no conflict, but that would change if this was implemented. The code may need adjustments to be thread-safe.

Parsing inputs can take a while in the `TRBot.Main` application after receiving a message, especially when factoring in everything that must be done, including running commands and the extensive post-processing. At least in the case of the Terminal and Twitch client services, the event loop sending message and command events are already run on their own threads. If two messages come in concurrently, it can't help but wait to completely finish processing one of them before moving onto the next. Consider moving all the code in `BotProgram.OnUserSentMessage` into a new thread and starting up this thread from the ThreadPool. This should make TRBot more responsive in popular streams and/or slower machines, and more efficiently utilize resources. However, keep in mind potential consequences. I forsee an issue with reloading data while it's parsing inputs or running commands. Since the `ReloadCommand` currently runs on the same thread as the input parsing, there's no conflict, but that would change if this was implemented. The code may need adjustments to be thread-safe.
kimimaru added the
refactor
enhancement
labels 6 months ago
Poster
Owner

The IncomingMessageThreading branch implements a new async Task that starts after initialization and continues running for TRBot's lifetime. Incoming commands and messages are put into a queue and processed one at a time inside that async method.

Testing in the Terminal client service so far, I'm already seeing improvements, even if minor. On develop, spamming inputs in the terminal causes the console to hang up until everything is done. However, on the IncomingMessageThreading branch, the console does not hang up while it's processing everything. This is progress!

However, race conditions with the database exist even on develop! Make sure #74 is completed before working on this further.

The [`IncomingMessageThreading` branch](https://codeberg.org/kimimaru/TRBot/src/branch/IncomingMessageThreading) implements a new async Task that starts after initialization and continues running for TRBot's lifetime. Incoming commands and messages are put into a queue and processed one at a time inside that async method. Testing in the Terminal client service so far, I'm already seeing improvements, even if minor. On develop, spamming inputs in the terminal causes the console to hang up until everything is done. However, on the `IncomingMessageThreading` branch, **the console does not hang up** while it's processing everything. This is progress! However, **race conditions with the database exist even on develop**! Make sure https://codeberg.org/kimimaru/TRBot/issues/74 is completed before working on this further.
kimimaru added this to the TRBot 2.4 project 6 months ago
Poster
Owner

Completed in a3a5c1ac96.

The database race conditions are not a regression, thus there's no obstacle in merging this.

Completed in https://codeberg.org/kimimaru/TRBot/commit/a3a5c1ac96f0df2827a76c2875feb292325e3746. The database race conditions are not a regression, thus there's no obstacle in merging this.
kimimaru closed this issue 5 months ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.