Greetings,
I believe I have narrowed down my issues to one simple question, and I'm hoping someone with async events experience can help me out.
My question is: how is using EventsHelper.FireAsync() different from using EventsHelper.Fire() BUT having the listener's event handler spawn a new thread to do the work?
In my program, I have a data feed coming in and I have a separate form that has a DataGridView on it. Each time a message comes in (they come in very rapidly) I fire an event and the handler (which exists on the DataGridView's form) adds a row to the DataGridView.
Approach #1: use EventsHelper.FireAsync() to fire the events as they come in. This is nice because the slowness of adding rows to the DataGridView control doesn't slow down the incoming data feed AT ALL -- meaning, if there were other listeners to this event, their performance wouldn't suffer from the slow DataGridView. HOWEVER, this approach doesn't work because of the asynchronous nature, the rows aren't necessarily added in order (message 3 might be processed/added to the DataGridView before messages 1 and 2).
Approach #2: use EventsHelper.Fire() (the synchronous version), and in the event handler, spawn a BackgroundWorker that adds the message to the DataGridView. I don't like this approach because then EVERY handler of this event is going to have to do all this extra work, but I figured it was the only way I could ensure the messages (events) would be received in order. However what I noticed is this approach (spawning the BackgroundWorker thread) doesn't really give a speed improvement over simply doing ALL the work in the same event thread.
Why isn't approach #2, with a BackgroundWorker in the ONLY event handler as fast as approach #1?
I love the speed EventsHelper.FireAsync provides, but I need to maintain order of the events. If anyone has any advice, I'm all ears.
Thanks in advance!
RL