Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Event dispatching backs up IO processing #8
Originally I wasn't too concerned about this, but now I am.
Dispatching events and invoking their callbacks within the IO processing thread is problematic for a couple reasons.
First, event callbacks are invoked either after an IO process cycle (connection events), or while
Second, if an event callback raises an exception, the end result (depending upon where the callback was invoked) will either be a shutdown of the connection, or a shutdown of the IO processor thread. While this isn't as big of a deal as it may initially seem, it's still a bit troubling and it makes my pants very angry.
I think the solution will be to introduce a thread for clients to enqueue events and invoke callbacks. This will create some new issues to be handled, such as:
The introduction of a new event dispatcher probably warrants a minor version increment, so all of this work will be committed to the 1.1.0 branch until it's ready to go.
The performance is now essentially the same as the previous approach. Read speed is a little faster, write speed fluctuates between slightly faster and slightly slower, so I'm going to call that "the same." The read performance becomes especially noticeable when dealing with large-ish frames (body size of 1 MB)